Add next_rails --init to replace next --init

[JuanVqz]

Description

1. I added a message to deprecate the current next --init command
   (eventually, we should remove it).
2. Moved the next --init functionality into the NextRails::Init class
3. Still need to move the bundle exec next functionallity. (next step? depends on the acceptance of this PR).

Motivation and Context

If the user has the next command installed from npm install -g next, the next --init command will not work.
This is a problem because the user will not know how to call the next command.

It is reported here:
Closes #113

How Has This Been Tested?

• I have tested this by running the next --init command and checking that the message is displayed.
• I have added automated tests to check the functionality of the NextRails::Init class.

Screenshots:

Added a deprecation warning when running next --init

When the command creates the Gemfile.next and Gemfile.next.lock it shows the same message as next --init has been showing:

If the next_rails --init gem was run previously and the Gemfile.next and Gemfile.next.lock already exist it does not run the command and shows a message instead.

Now the --init command is part of the --help output

I will abide by the code of conduct

[etagwerker]

@JuanVqz This looks good to me, but I'd like you to use fakefs in the tests. Could you please look into that?

https://github.com/fakefs/fakefs

[JuanVqz]

@JuanVqz This looks good to me, but I'd like you to use fakefs in the tests. Could you please look into that?

https://github.com/fakefs/fakefs

@etagwerker I like the idea of using the fakefs gem; however, if we are planning on supporting older Ruby versions (2.0, 2.3, etc...), it would be complicated, the early fakefs v0.14.0 was already requiring Ruby >= 2.3.0 as for the latest fakefs v3.0.0 it requires at least Ruby 3.0.

So, do you think we should still wanting to include that gem?

[etagwerker]

Oh good point. Then I think it's okay to skip it