Provide Macaw with driver-based formatting options

[crisptrutski]

In order to correctly handle case and quoting during SQL rewrites, we need to be driver-aware.

As a first version we'll expect Metabase to pass in some relevant config, and keep Macaw itself driver agnostic.

{:case-insensitive? true
 :quotes            "[]" ;; MSSQL

Perhaps we're able to leverage existing driver methods used by the query processor, especially for the quotes. Otherwise, new multimethods with sensible defaults (thinking case sensitive, with double quotes for quotes).

In future we might find the need to have dialect specific grammars, in which case this will seem a bit redundant. We'll probably keep a fairly agnostic superset grammar as fallback for newfangled 3rd party drivers, which will still take these options though.

[crisptrutski]

It turns out that:

1. Macaw as it stands can't support [] quoting. Hacking around that can happen just as well in Metabase as in Macaw, so I'd prefer to keep the library "clean" for now.
2. Most common dialect support the same two quotes, so just handle them for everything.
3. Whether quotes affect case sensitivity differs by dialect, so I added an extra option for that.

So the options we need are now the following:

{
  :case-insensitive? true ;; ignore case when comparing identifiers
  :quotes-preserve-case? true ;; ignore :case-insensitive? for quoted references?
}

[crisptrutski]

It turns out that MySQL's behavior doesn't quite fix any of the patterns we expected. There was a bit of a crossed wire when discussing this with Sanya in the related issue as well, where it turns out he was actually talking about case sensitivity when comparing the values of string typed columns.

To summarize MySQL behavior:

• Databases and tables are case sensitive depending on the the file systems it's using, and the lower_case_table-names system variable. The default value of this variable comes from the OS the DB was created on.
• The semantics of that system variable are quite complex, but as far as we care if the value is 0 then we know that it's running on a case insensitive FS and case is not being normalized. If it is any other value then these identifiers are not treated as case sensitive.
• We can check this system variable by querying the connection, and its value can never change, so it's safe to cache.
• Column names and aliases are never case sensitive, even if you quote them.

For a v1 I think we can just treat MySQL as never being case sensitive, since in practice it's a strongly discouraged practice to use non lowercase names in the database and table names.

For a v2 we could change the Macaw API to allow case sensitivity to be set on a per-identifier-type basis, and to get some of these values from the database. We could keep this per-database configuration in a in-memory cache to avoid database hits every time we analyze a query, and we could save this as a property of the database when we first connect to it.

That's quite a few moving parts for something customers are unlikely ever to run into, so I think it's fair to kick it down the road.