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.
Janitorial work... (Two small code cleanups)

1. Call the ServiceCollection.AddXxx methods with fewer generic arguments now that the DI APIs have been updated to allow this.
2. Stop passing in CancellationToken.None where not required because of default argument.
Added APIs to ModelBuilder to be able to construct a model without requiring CLR types.
Updated the CSharpModelCodeGenerator to generated code that uses the new APIs.
Added and updated unit tests.
Updated README to point to Wiki
Adding csproj files for non-K tooling experience
Removing legacy k10 csproj files
Update project files to latest drops
Fixing SQLite refs
Add hack to make immutable collections work when running tests on net45
Rename .csproj files
Dynamically reference NuGet packages
Virtua Fighter II (Update virtual method meta-test to require virtual for interface implementations)
- Initial work on relational projection
- Basic OrderBy and Take
Code cleanup
Adding some R# suppressions
Adds SQLite FTs stub project
Initial support for SingleX, FirstX and Distinct operators in Relational
Fixing merge typo
Bridging the generation gap... (Integrate value generators with data stores)

This change covers two main areas:
1. The StoreValueGenerationStrategy enum is replaced with two new enums--one to determine what kind of value generation to do when the entity is added to the context, and one to determine the kind of value generation that happens on the server when SaveChanges is called. A third enum for configuration of default value use is envisioned but is not included here.
2. Re-working of the generators and related infrastructure so that a data store can control which generator is used and so that a database connection from the session can be used in the value generation process.

More specifically:
- Each data store has a cache of generators that are being used. This allows generators to hold state, such as the next value to generate.
- For each logical generator the cache can contain a pool of actual generators. This is currently only used for SQL Server sequence generators so that multiple blocks can be used at once for a given sequence, which can in-turn reduce the chance that all requests are blocked waiting for a new block to be created on the server.
- Each generator type has its own factory which is responsible for creating an instance of the generator and also providing information used to manage the pool of generators--for example, the pool size and the key used to store the generators in the cache. So, for example, all SQL Server sequence generators could use the same sequence in the database in which case only a single pool would be used for all properties that use this sequence. Currently the default is to create a different database sequence for each table, but we can discuss whether or not this is the best default.
- Each data store also has a selector which is responsible for deciding which kind of generator to use based on the property type and associated metadata--basically whether or not the value should be generated on the client or on the server.

I believe that the SQL server sequence generator (and its pool) is not asynchronously thread-safe.

Some things that still need to be done:
- The fluent API for using store sequence is currently part of the code code, but it should probably be relational-only.
- Integration into Migrations is needed so that the store sequences will be created appropriately.
- No SQLite value generation yet
Simplify project.json files