[Andrey Novikov & Łukasz Sarnacki]

This was only used for uniqueness validations. The first usage was in
conjunction with `limit`. Types which cast to string, but are not
considered text cannot have a limit. The second case was only with an
explicit `:case_sensitive => true` option given by the user.

All cases except for `nil` in an array have been removed. `nil` in an
array is handled by the Array type object.

adapter, fixed from #16057 [ci skip]

We default to making the connection strict, but have historically relied
on the MySQL default when we want it to be non-strict. On some (recent?)
versions of MySQL, new connections default to being strict, so if we've
been told 'strict:false', we're obliged to pass that on.

This fixes a test failure that we've seen turn up on relatively-new
development machines, so we do already have a test covering it.

The test case for CVE-2014-3483 doesn't actually send the generated SQL
to the database. The generated SQL is actually invalid for real inputs.

Fix CVE-2014-3483 and protect against CVE-2014-3482.

Note: I'm not sure we actually need to be logging when this happens.
This code would be a fair bit cleaner if we didn't need to log it.

Hstore no longer needs additional quoting to be used in an array, the
array type handles it sufficiently.

We no longer need to do fancy legwork to make sure arrays use a type
object, now that schema methods use a real type object.

The only case where we got a column that was not `nil`, but did not
respond to `cast_type` was when type casting the default value during
schema creation. We can look up the cast type, and add that object to
the column definition. Will allow us to consistently rely on the type
objects for type casting in all directions.

The name of the foreign key is not relevant from a users perspective.
Using random names resolves the urge to rename the foreign key when the
respective table or column is renamed.

This allows to create and remove foreign keys without specifying a column.