Use connection-specific bytea escaping

In our normal usage, it's rare for this to make a difference... but is
more technically correct.

As well as a spec that proves this is a good idea, let's also add a more
sane-looking one that just covers basic to_sql functionality. There
aren't many places where we actually use escape_bytea, but that's one
that won't be going away.
Merge pull request #14632 from matthewd/escape_bytea

Use connection-specific bytea escaping
Build the reverse_order on its proper method.

The reverse_order method was using a flag to control if the order should
be reversed or not. Instead of using this variable just build the reverse order
inside its proper method.

This implementation was leading to an unexpected behavior when using
reverse_order and then applying reorder(nil).

Example:
  Before
    Post.order(:name).reverse_order.reorder(nil)
    # => SELECT "posts".* FROM "posts"   ORDER BY "posts"."id" DESC

  After
    Post.order(:name).reverse_order.reorder(nil)
   # => SELECT "posts".* FROM "posts"
Remove useless begin..end
remove check for present? from delete_all

Passing in a blank string is a bug so there's no reason
to check for a blank string.
Rails.application should be set inside before_configuration hook

Fixes #14620
Merge pull request #14635 from eileencodes/remove-check-for-present

remove check for present? from delete_all method
Merge pull request #14634 from laurocaetano/fix_reorder

Build the reverse_order on its proper method.
Merge pull request #14633 from matthewd/narrow_database_url

Only apply DATABASE_URL for Rails.env
Make sure DEFAULT_URL only override current environment database
configuration
Test DATABASE_URL has precendance over DATABASE_URL_#{environment}
Only call DEFAULT_ENV proc one time
Check env_url only once
entry is always a Hash
Rearrange the config merger some more

This seems to simplify the operative part. Most importantly, by
pre-loading all the configs supplied in ENV, we ensure the list is
complete: if the developer specifies an unknown config, the exception
includes a list of valid ones.
Give a deprecation message even when the lookup fails

If the supplied string doesn't contain a colon, it clearly cannot be a
database URL. They must have intended to do a key lookup, so even though
it failed, give the explanatory deprecation warning, and raise the
exception that lists the known configs.

Conveniently, this also simplifies our logical behaviour: if the string
matches a known configuration, or doesn't contain a colon (and is
therefore clearly not a URL), then we output a deprecation warning, and
behave exactly as we would if it were a symbol.
Ensure we correctly and immediately load all ENV entries

.. even when the supplied config made no hint that name was relevant.