Oracle specifically has long unrounded decimals that cause tests to
fail. This munges results to round the decimals to 3 places before comparing.

This commit reworks binning to use the new fingerprint field added
during analysis, rather than the (no longer existing) min/max columns
on the metabase_fields table.

call (data/db) or (data/id)

The mbql clause is nil, so when chosen it will not change or add to
the query in any way.

Expectations needed to be updated with new data that is being returned.

* fix name and order of everything else collection

* modernize card picker component

* return proper name from api

* update test

This commit adds a new keypair to the fields map called
"default_dimension_option". For datetimes, this is grouping by day,
for binning this is the "default" binning strategy.

This hadn't been updated to allow for the two binning strategies that
we now support.

External remappings are only supported on drivers that have foreign
keys. A new test was added to for ordering by the remapped but it
wasn't narrowed to only engines that support foreign keys. This commit
fixes that text.

If a field is set to an enum or category type and has a remapping,
that should be cleared if the field moves to a special_type that is
not allowed to have remappings (i.e. text). This commit adds checks
for that and clears the dimension in that case.

If a field is set to an enum or category type and has a remapping,
that should be cleared if the field moves to a special_type that is
not allowed to have remappings (i.e. text). This commit adds checks
for that and clears the dimension in that case.

The previous commit fixed a bug when there is no order by, but there
is a remapping. The corresponding change to the
add-dimmension-projections-test didn't happen. This fixes that test failure.

When an MBQL query has an order by for a column that has been
remapped via FK, it will swap the order by for the original field for
the remapped field. Previously this would order by the original source
column and apply that to the remapping which would be unexpected.

If we have an external remapping, human_readable_field_id is
required. We now return a 400 if that is missing.

Currently this is used similarly to category. As we get more remapping
features (booleans, strings etc) this will be different from
categories and won't have the existing category baggage.

One of the tests added recently changes the special_type of
category_id. It should have save what it's original value was and
restored it after it was done instead of assuming it's previous value
was nil.

This makes the query_metadata route behavior similar to the field
values route.

This reverts commit 95a65d42.

Specifically updating a field attribute that wasn't it's type or it's
fk_target_field_id would cause this issue