Creates a component that can be used for the common pattern of writing out
serialized data to a staging location for later committing to the destination,
or using in some other way. We've repeated very similar code for many existing
SQL warehouse materializations and it felt like it was time to consolidate the
common behaviors.

The immediate use will be in the the new Azure Fabric Warehouse materialization.
It could be retroactively incorporated into existing materializations in order
to simplify them, but I'm not going to do that right now, at least until it has
been proven with the brand new one.

The integration tests for materialize-azure-fabric-warehouse. Adding these as a
separate commit for ease of review. The actual connector code that can run them
will be in a subsequent commit.

Basic working version of the Azure Fabric Warehouse materialization.

Fabric Warehouse is a relatively new product, and perhaps because of that it is
missing some features typical of other SQL warehouse materializations:

* No merge query support: This means we must delete rows from the target table
  that already exist, before inserting the updated rows. I don't think this is
  all that much different than what a true merge query would do, but it's a
  little more cumbersome to build queries for.
* No ability to read from staged files directly; instead we must load them into
  "temporary" tables using a COPY INTO query.
* Fabric Warehouse recently added support for temporary tables, but
  unfortunately COPY INTO does not work with them. An actual table must be
  created, COPY INTO'd, and then later dropped when it is not needed. Fabric
  Warehouse does at least support creating and dropping tables within a
  transaction, and this is utilized to ensure we don't leave tables hanging
  around.
* No idempotent COPY INTO, which makes a post-commit apply strategy with
  exactly-once standard and delta updates impossible. Transactions are supported
  though, and there don't appear to be any strange limitations on them like
  number of tables in a single transaction, so the authoritative endpoint
  pattern works well.

Other than these main limitations, a decent range of data types is supported,
and the materialization seems to work pretty well.

Later commits will add support for additional features like column migrations,
and some additional optimizations.

Column migrations can't be done with the typical column renaming strategy since
Fabric Warehouse doesn't support dropping columns from a table, but it does
support creating, dropping, and renaming columns within a transaction.

It seems that the accept workaround for migrating column types is to create a
new table, copying the unchanged column values and casting the changed ones as
appropriate, and then swap that table for the old one by dropping the old one
and renaming the new one.

The previous commit for Fabric Warehouse modified the column migration tests to
show how integer column widening works, where a schema that was previously
compatible with a 64-bit integer column is now known to be too large for that,
but not so large as to not fit into some other exact integer representation
column.

This adds support for all of the other SQL migrations for integer widening
migrations, and updates their test snapshots.

Binary columns can be created as VARBINARY(MAX), and binary data can be loaded
into them using the `BASE64_DECODE` from staged base64-encoded strings.

There's a bit of extra complexity for templating out where this decoding is
necessary, and dealing with binary keys and their required comparison
operations.

This seems to get the job done, although it makes the query templates harder to
comprehend.

…zations

Track the range of observed keys for load and merge queries, and provide query
hints to hopefully limit the amount of data that must be scanned when running
these queries.

We have done similar merge query optimizations for materialize-bigquery and
materialize-snowflake. This is the first example of also doing it for load
queries.

… files

Each file needs to be enclosed in single quotes, rather than the entire list of
files.

A string field that is present in a document with a value of 0-length, AKA the
string "", is different than a string field that is absent.

The stdlib Go CSV writer does not allow for such a distinction to be made,
since all fields must be strings and there is no way to indicate an "absent"
string.

This commit implements a custom CSV writer that can tell the difference between
an absent and 0-length string. An absent string gets "skipped", with no value at
all placed between the commas of a row. A 0-length string gets quoted to just be
"". Other strings get quoted if they have special characters requiring quotes;
otherwise they are written as-is.

This new CSV writer is inspired by the Go stdlib CSV writer, with the required
additions for absent vs. empty string. Some of the extra configuration that we
generally don't need has been stripped out like specifying a special NULL
string, and using a custom "comma" value - nobody has ever used these options in
our filesink materializations, and it seems reasonable to not support them
unless somebody requests them down the line. This custom CSV writer also does
not use an additional internal buffer, since this is redundant with the
buffer(s) that are inevitably used by its outputs.