Changed default of isClustered of primary key to true.
Added unit test.
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.
Update README.md
Update README.md
Tidy up text and add link to EF sample code
Create CONTRIBUTING.md
Magic emerges from simplicity... (Updates to database creation APIs)

The idea here is to follow a pattern of very simple, very non-magical, commands for the basic operations which can then be composed into more complex operations. The simple commands are:
- Exists: True if database exists; false if it doesn't
- HasTables: True if the database has any tables; false if it doesn't; potentially throw if the database doesn't exist
- Create: Create an empty database or potentially throw if a database with the given name already exists
- Delete: Delete an exist database or potentially throw if the database doesn't exist

None of these commands do existence checking because this has proven to be problematic in many situations and providing these building block commands thus allows the most flexibility for people to get the behavior they need without being dependent on things like exists checks that may not work. For example, you may have some mechanism in your app/infrastructure that tells you this is the first run and therefore the database cannot exist and needs to be created. With these commands this can still be mad to work even if there the exists check we would do does not work with the provider/environment you have.

All that being said, there are two common things that people do, so there are two higher-level composed commands provided out-of-the-box:
- EnsureCreated will create the database if it doesn't exist and create tables for the model if the database doesn't have any tables. It will do nothing if the database exists and has any tables in it.
- EnsureDeleted will delete the database if it exists or do nothing if the database doesn't exist.

SQL Server and In Memory implementations provided and tested, although not yet tested against SQL Azure. SQLite implementation provided but not tested since there are currently no SQLite tests.

See Issue #161
Varying double precision with time zone... (Moved SQL Server-specific type mapping into SQL Server assembly and added tests)

Added tests for type mapping code checked in previously and at the same time moved the SQL Server specific mappings into the SQL Server assembly and checked that providers can override mappings.
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.