It's finally finished!!!!!!! The reason the Attributes API was kept
private in 4.2 was due to some publicly visible implementation details.
It was previously implemented by overloading `columns` and
`columns_hash`, to make them return column objects which were modified
with the attribute information.

This meant that those methods LIED! We didn't change the database
schema. We changed the attribute information on the class. That is
wrong! It should be the other way around, where schema loading just
calls the attributes API for you. And now it does!

Yes, this means that there is nothing that happens in automatic schema
loading that you couldn't manually do yourself. (There's still some
funky cases where we hit the connection adapter that I need to handle,
before we can turn off automatic schema detection entirely.)

There were a few weird test failures caused by this that had to be
fixed. The main source came from the fact that the attribute methods are
now defined in terms of `attribute_names`, which has a clause like
`return [] unless table_exists?`. I don't *think* this is an issue,
since the only place this caused failures were in a fake adapter which
didn't override `table_exists?`.

Additionally, there were a few cases where tests were failing because a
migration was run, but the model was not reloaded. I'm not sure why
these started failing from this change, I might need to clear an
additional cache in `reload_schema_from_cache`. Again, since this is not
normal usage, and it's expected that `reset_column_information` will be
called after the table is modified, I don't think it's a problem.

Still, test failures that were unrelated to the change are worrying, and
I need to dig into them further.

Finally, I spent a lot of time debugging issues with the mutex used in
`define_attribute_methods`. I think we can just remove that method
entirely, and define the attribute methods *manually* in the call to
`define_attribute`, which would simplify the code *tremendously*.

Ok. now to make this damn thing public, and work on moving it up to
Active Model.

changed deleted_tables list to set

Fix STI for fixtures from multi-files

This method doesn't need to be lazy, as it is never called from reads.
The only time it is called are in write cases, where we're about to loop
through the results of it, and build the attribute objects anyway. So we
don't gain anything by dodging the instantiation here. This is the only
method that coupled `AttributeSet` to `LazyAttributeHash`, so removing
it puts us back in a place where we can use a normal hash instead.

Provide a better error message on :required association

Add Single Table Inheritance to guides [ci skip]

Improving 'Customizing Form Builder' section with example [ci skip]

Fixed test for deprecation warning in actionview for kwargs

Fixed test for deprecation warning in actionview, renaming from https://github.com/rails/rails/commit/baf14ae513337cb185acf865e93dfc48f3aabf6a

Fix a typo in deprecation warning. #process takes method instead of http_method.

This means we know generation works with this version, it does not
mean it does not work with the last releases (should be tested).

[ci skip] Document format parameter of process method in AC test_case.

Mostly cosmetics, except that `isolate_namespace` should be applied to the last
module in the chain.

Allow hyphenated names for `rails plugin new` generator

Unfortunately, the HashWithIndifferent access approach is insufficient
for our needs. It's perfectly reasonable to want to use keyword
arguments with Active Job, which we will see as a symbol keyed hash. For
Ruby to convert this back to keyword arguments, it must deserialize to a
symbol keyed hash.

There are two primary changes to the serialization behavior. We first
treat a HWIA separately, and mark it as such so we can convert it back
into a HWIA during deserialization.

For normal hashes, we keep a list of all symbol keys, and convert them
back to symbol keys after deserialization.

Fixes #18741.

Remaining are `limit`, `precision`, `scale`, and `type` (the symbol
version). These will remain on the column, since they mirror the options
to the `column` method in the schema definition DSL

The goal is to remove the type object from the column, and remove
columns from the type casting process entirely. The primary motivation
for this is clarity. The connection adapter does not have sufficient
type information, since the type we want to work with might have been
overriden at the class level. By taking this object from the column,
it is easy to mistakenly think that the column object which exists on
the connection adapter is sufficient. It isn't.

A concrete example of this is `serialize`. In 4.2 and earlier, `where`
worked in a very inconsistent and confusing manner. If you passed a
single value to `where`, it would serialize it before querying, and do
the right thing. However, passing it as part of an array, hash, or range
would cause it to not work. This is because it would stop using prepared
statements, so the type casting would come from arel. Arel would have no
choice but to get the column from the connection adapter, which would
treat it as any other string column, and query for the wrong value.

There are a handful of cases where using the column object to find the
cast type is appropriate. These are cases where there is not actually a
class involved, such as the migration DSL, or fixtures. For all other
cases, the API should be designed as such that the type is provided
before we get to the connection adapter. (For an example of this, see
the work done to decorate the arel table object with a type caster, or
the introduction of `QueryAttribute` to `Relation`).

There are times that it is appropriate to use information from the
column to change behavior in the connection adapter. These cases are
when the primitive used to represent that type before it goes to the
database does not sufficiently express what needs to happen. An example
of this that affects every adapter is binary vs varchar, where the
primitive used for both is a string. In this case it is appropriate to
look at the column object to determine which quoting method to use, as
this is something schema dependent.

An example of something which would not be appropriate is to look at the
type and see that it is a datetime, and performing string parsing when
given a string instead of a date.  This is the type of logic that should
live entirely on the type. The value which comes out of the type should
be a sufficiently generic primitive that the adapter can be expected to
know how to work with it.

The one place that is still using the column for type information which
should not be necessary is the connection adapter type caster which is
sometimes given to the arel table when we can't find the associated
table. This will hopefully go away in the near future.

The test added in 85465ed3 was passing
when the file was run on its own, but failing when the entire suite was
run since this test modifies the class and doesn't clean up.

It was not possible to create a new gem with a hyphenated name via the `rails plugin new` generator.

The naming guide of rubygems clearly says dashes should be used for gems that extend other gems. http://guides.rubygems.org/name-your-gem/

Collection associations would have already been validated, but singular
associations were not.

Fixes #18735.

This prevents a flood of warnings when generating a new scaffold.

Fix grammar in Qualified Constants section [ci skip]

New wording is based on the "cref" sentence earlier in the section.

[ci skip]

Improvements about schema dumping [ci skip]

Add a margin to body and padding to th, td in scaffold.css.

Add space to new css defs.

Doc: run bundle update after cloning Rails.

Update option to skip test in generators