When generating models, we created ApplicationRecord in the default
location if no file existed there.  That was annoying for people who
moved it to somewhere else in the autoload path.  At this point, the
vast majority of apps should have either run the upgrade script or
generated a model since upgrading.  For those that haven't the error
message after generating a new model should be helpful:

   NameError: uninitialized constant ApplicationRecord

To ease friction in that case, this also adds a generator for
ApplicationRecord.

Currently, `app:update` generates all contents regardless of the
component using in application.

For example, even if not using Action Cable, `app:update` will generate
a contents related to Action Cable. This is a little inconvenient.
This PR checks the existence of the component and does not generate
unnecessary contents.
Can not check all options in this way. However, it will be able to
prevent the generation of unnecessary files.

This reverts commit 3420a145, reversing
changes made to afb66a5a.

The `capify` command has been removed by Capistrano 3 and became to
`cap install`.
Therefore, the `capify!` method has no meaning in Capistrano 3.
I think that should deprecate.

Ref: https://github.com/capistrano/capistrano/commit/492793916acf32ffe1604daec6fd4892c8935018

Fixes #29247

".. with __dir__ we can restore order in the Universe." - by @fxn

Related to 5b8738c2

Allows users to not have remote forms by default, since there's
more JS harness, e.g. bundling rails-ujs, otherwise.

Also don't skip creating defaults file anymore. Sprockets isn't the only new config.

This is a follow up to a6d065e3. When using `form_with` you must supply
field ids manually. Since the scaffold generator is using labels we
need to make sure that they are linked up properly.

The "-j" option was added 5 years ago (https://github.com/rails/rails/commit/d9c39c3a)
when we wanted to support prototype-rails and jquery-rails.
Prototype is not as popular and jQuery is not a requirement anymore.
Still the "-j" option can be used to install *any* gem that ends in "-rails".

This "might" open security issues and does not bring great benefits anymore.

If you know which "-rails"-ending gem you want to install, you can manually
add it to the Gemfile just like any other gem.

This is necessary only when updating to Rails 5.0, it is not necessary
for updating to 5.1.

Related #24243

More intention revealing and means `f` can go F itself 😋

Occasionally we update the file generated by engine.
Therefore, I think that there is a task for updating as well as
application in the engine, it is convenient for updating.

This fixes the following warnings:

```
railties/test/generators/encrypted_secrets_generator_test.rb:15: warning: character class has duplicated range: /[\w\d]+/
railties/test/generators/encrypted_secrets_generator_test.rb:18: warning: character class has duplicated range: /production:\n#  external_api_key: [\w\d]+/
railties/test/generators/encrypted_secrets_generator_test.rb:19: warning: character class has duplicated range: /production:\n#  external_api_key: [\w\d]+/
```

It can not check correctly with `defined?`

```ruby
irb(main):001:0> Rails.application.config.active_record
=> {:maintain_test_schema=>true, :belongs_to_required_by_default=>true}
irb(main):002:0> defined?(Rails.application.config.active_record)
=> nil
```

Follow up to #28469

Instead of forcing new applications to carry an initializer that just
switches things to what their default "should" be, we can handle it
internally.

The initializer is then only used by upgraders: it shows what the new
default would be (commented out), while their upgraded application
continues to operate as it did before.

Under this model, a multiply-upgraded application could accumulate
several new_framework_defaults_*.rb files, for each release series it
has traversed. A given release series only needs to generate the latest,
though, because we don't support `rails app:upgrade` while skipping
releases.

`rails:update` was changed to `app:update` in 6fb31638.
Therefore, I think that it is better that the test name is also `app_update`.

Instead of calling methods of Rails.application directly, we need to
use a method that is considered for the rails engine.

Whether the command was executed within the rails application is checked
by whether or not the application's path matches `app_path`.
https://github.com/rails/rails/blob/5-0-stable/railties/lib/rails/generators/rails/plugin/plugin_generator.rb#L439..L441

Therefore, if only plugin name is specified in `app_path`, addition to
Gemfile is not done.
However, in the rails guide an example of specifying only plugin name
is given, and it is considered that there are many cases where only
plugin name is specified.
For that reason, made it work even if only plugin name was specified.

ref this commit seems that has not been merged into 3.7 https://github.com/puma/puma/commit/42bec4600c51ab8a1c1ee5a0e1b738a4ffd82bf2

* Move system tests back into Action Pack
* Rename `ActionSystemTest` to `ActionDispatch::SystemTestCase`
* Remove private base module and only make file for public
`SystemTestCase` class, name private module `SystemTesting`
* Rename `ActionSystemTestCase` to `ApplicationSystemTestCase`
* Update corresponding documentation and guides
* Delete old `ActionSystemTest` files

Renames `Rails::SystemTestCase` to `ActionSystemTest` and moves it to a
gem under the Rails name.

We need to name the class `ActionSystemTestCase` because the gem expects
a module but tests themselves expect a class.

Adds MIT-LICENSE, CHANGELOG, and README for the future.

* Adds test case test
* Adds driver adapter test
* Adds tests for capybara seleium driver (testing the settings not
actually opening the browser to test capybara w/ selenium because that
would so so so slow)
* Adds tests for rack test driver
* Adds tests for generators