Currently dumping defaults on schema is inconsistent.

Before:

```ruby
  create_table "defaults", force: :cascade do |t|
    t.string   "string_with_default",   default: "Hello!"
    t.date     "date_with_default",     default: '2014-06-05'
    t.datetime "datetime_with_default", default: '2014-06-05 07:17:04'
    t.time     "time_with_default",     default: '2000-01-01 07:17:04'
    t.decimal  "decimal_with_default",  default: 1234567890
  end
```

After:

```ruby
  create_table "defaults", force: :cascade do |t|
    t.string   "string_with_default",   default: "Hello!"
    t.date     "date_with_default",     default: "2014-06-05"
    t.datetime "datetime_with_default", default: "2014-06-05 07:17:04"
    t.time     "time_with_default",     default: "2000-01-01 07:17:04"
    t.decimal  "decimal_with_default",  default: "1234567890"
  end
```

This reverts commit 671eb742.

This is not a change we would like moving forward.

ie. DecimalWithoutScale, Text and UnsignedInteger

ActiveModel::Type)

Some code was previously referring to ActiveModel::Type::*. This could
cause issues in the future if any of the ActiveRecord::Type classes were
overridden in the future.

Test: JSON attribute value nil can be used in where(attr: nil)

Add changelog entry

For reduce instantiating `Type::Value`.

The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.

When looking for mutation, we compare the serialized version of the
value to the before_type_cast form. `Type::Serialized` was breaking this
contract by passing the already serialized attribute to the subtype's
mutation detection. This never manifested previously, as all mutable
subtypes either didn't do anything in their `serialize` method, or had a
way to detect double serialization (e.g. `is_a?(String)`). However, now
that JSON types can handle string primitives, we need to avoid double
serialization.

Fixes #24993.

Context #24522.

TIME column on MariaDB doesn't ignore the date part of the string when
it coerces to time.

```
root@localhost [test] > CREATE TABLE `foos` (`id` int AUTO_INCREMENT PRIMARY KEY, `start` time(0), `finish` time(4)) ENGINE=InnoDB;
Query OK, 0 rows affected (0.02 sec)

root@localhost [test] > INSERT INTO `foos` (`start`, `finish`) VALUES ('2000-01-01 12:30:00', '2000-01-01 12:30:00.999900');
Query OK, 1 row affected, 2 warnings (0.00 sec)

Note (Code 1265): Data truncated for column 'start' at row 1
Note (Code 1265): Data truncated for column 'finish' at row 1
root@localhost [test] > SELECT `foos`.* FROM `foos`;
+----+----------+---------------+
| id | start    | finish        |
+----+----------+---------------+
|  1 | 12:30:00 | 12:30:00.9999 |
+----+----------+---------------+
1 row in set (0.00 sec)

root@localhost [test] > SELECT  `foos`.* FROM `foos` WHERE `foos`.`start` = '2000-01-01 12:30:00' LIMIT 1;
Empty set (0.00 sec)

root@localhost [test] > SELECT  `foos`.* FROM `foos` WHERE `foos`.`start` = '12:30:00' LIMIT 1;
+----+----------+---------------+
| id | start    | finish        |
+----+----------+---------------+
|  1 | 12:30:00 | 12:30:00.9999 |
+----+----------+---------------+
1 row in set (0.00 sec)
```

Previously we were assuming that the only valid types for encoding were
arrays and hashes. However, any JSON primitive is an accepted value by
both PG and MySQL.

This does involve a minor breaking change in the handling of `default`
in the schema dumper. This is easily worked around, as passing a
hash/array literal would have worked fine in previous versions of Rails.
However, because of this, I will not be backporting this to 4.2 or
earlier.

Fixes #24234

This moves a bit more of the logic required for dirty checking into the
attribute objects. I had hoped to remove the `with_value_from_database`
stuff, but unfortunately just calling `dup` on the attribute objects
isn't enough, since the values might contain deeply nested data
structures. I think this can be cleaned up further.

This makes most dirty checking become lazy, and reduces the number of
object allocations and amount of CPU time when assigning a value. This
opens the door (but doesn't quite finish) to improving the performance
of writes to a place comparable to 4.1

Things like decorations, overrides, and priorities only matter for
Active Record, so the Active Model registry can be implemented much more
simply. At this point, I wonder if having Active Record's registry
inherit from Active Model's is even worth the trouble?

The Active Model class was also missing test cases, which have been
backfilled.

This removes the error when two types are registered with the same name,
but given that Active Model is meant to be significantly more generic, I
do not think this is an issue for now. If we want, we can raise an error
at the point that someone tries to register it.

We do not need to require each file from AM individually, the type
module does that for us. Even if the classes are extremely small right
now, I'd rather keep any custom classes needed by AR in their own files,
as they can easily have more complex changes in the future.

These are used by the connection adapters to convert SQL type
information into the appropriate type object, and makes no sense outside
of the context of Active Record

The first step of bringing typecasting to ActiveModel

The thread_safe gem is being deprecated and all its code has been merged
into the concurrent-ruby gem. The new class, Concurrent::Map, is exactly
the same as its predecessor except for fixes to two bugs discovered
during the merge.

[Rafael Mendonça França + Jean Boussier]

Several changes were made in #21110 which I am strongly opposed to.
(this is what I get for going on vacation. :trollface:) No type should
be introduced into the generic `ActiveRecord::Type` namespace, and
*certainly* should not be registered into the registry unconstrained
unless it is supported by *all* adapters (which basically means that it
was specified in the ANSI SQL standard).

I do not think `# :nodoc:` ing the type is sufficient, as it still makes
the code of Rails itself very unclear as to what the role of that class
is. While I would argue that this shouldn't even be a super class, and
that MySql and PG's JSON types are only superficially duplicated (they
might look the same but will change for different reasons in the
future).

However, I don't feel strongly enough about it as a point of contention
(and the biggest cost of harming the blameability has already occured),
so I simply moved the superclass into a namespace where its role is
absolutely clear.

After this change, `attribute :foo, :json` will once again work with
MySQL and PG, but not with Sqlite3 or any third party adapters.

Unresolved questions
--------------------

The types that and adapter publishes (at least those are unique to that
adapter, and not adding additional behavior like `MysqlString` should
probably be part of the adapter's public API. Should we standardize the
namespace for these, and document them?

As of MySQL 5.7.8, MySQL supports a native JSON data type.

Example:

    create_table :json_data_type do |t|
      t.json :settings
    end

We were never clearing the `PG::Result` object used to query the types
when the connection is first established. This would lead to a
potentially large amount of memory being retained for the life of the
connection.

Investigating this issue also revealed several low hanging fruit on the
performance of these methods, and the number of allocations has been
reduced by ~90%.

Fixes #19578

This is obviously all very internal, but sometimes you have to look at
it... and when you do, it'll save a lot of confusion if it doesn't lie
about its identity.

The subtype will (quite reasonably) ignore the possibility that it has
`changed_in_place?` by becoming nil.

Fixes #19467

* Fix a few typos
* Wrap some lines around 80 chars
* Rephrase some statements

It is also necessary to format a time column like a datetime column.

This helper no longer makes sense as a separate method. Instead I'll
just have `deserialize` call `cast` by default. This led to a random
infinite loop in the `JSON` pg type, when it called `super` from
`deserialize`. Not really a great way to fix that other than not calling
super, or continuing to have the separate method, which makes the public
API differ from what we say it is.

We do this in the adapter classes specifically, so the types aren't
registered if we don't use that adapter. Constants under the PostgreSQL
namespace for example are never loaded if we're using mysql.

As per previous discussions, we want to give users the ability to
reference their own types with symbols, instead of having to pass the
object manually. This adds the class that will be used to do so.

    ActiveRecord::Type.register(:money, MyMoneyType)

The latest version of the PG gem can actually convert the primitives for
us in C code, which gives a pretty substantial speed up. A few cases
were only there to add the `infinity` method, which I just put on the
range type (which is the only place it was used). Floats also needed to
parse `Infinity` and `NaN`, but it felt reasonable enough to put that on
the generic form.

The various databases don't actually need significantly different
handling for this behavior, and they can achieve it without knowing
about the type of the object.

The old implementation was returning a string, which will cause problems
such as breaking TZ aware attributes, and making it impossible for the
adapters to supply their logic for time objects.

If timestamp column have the precision, it need to format according to
the precision of timestamp column.