Part1
Even beer pipelines exist... (Allow typed DbParameter creation in update pipeline)

Previously we were always inferring the type of DbParameter from the parameter value. This doesn't work in general because sometimes the type cannot be inferred (e.g. nulls) and sometimes the inference is wrong (e.g. DateTime => datetime instead of datetime2).

While trying to fix this is became apparent that the pipeline was doing many transformations to ad-hoc structures of tuples, string, and objects. This made it hard to get proper parameter creation because flowing the information to the right place requires updating all these data structures. I tried to simplify this and found that once simplified the use of the store model wasn't providing any value, so I removed this as well. This got to a point where value propagation, parameter creating, and command building became simpler. For example, there was no longer any need to map reader values back to state entries using column names because the order of the columns in the reader is known and can be used directly.

I also realized that the batching code we have will only ever create a batch of one and so isn't really exercised in the code. I left the code in place with a TODO. Discussions with others leads me to believe we will need to change the SQL that is generated in the future anyway and this may change the batching code as well. I did remove the code for reading non-identity computed keys--this will be added back as part of the work to rationalize how store-generated values are handled.

Quoting of identifiers was added.

Common store type mapping is now used for Migrations and the update pipeline. This is all in the base relational provider for now, but some of it will need to move into the SQL Server provider.

Testing still underway.