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
Add csproj to sln and add skeleton code rowanmiller
Beginnings of a provider for Azure Table Storage.

Add null checks on public interfaces.
Batching is now configured per context.
Wrap Azure SDK in more testable interfaces and wrappers. Fix async issues on fetching
Update datastore to match new API.
Minor tweaks. Change batching setup to use configuration.
Whitespace fixes (R# code cleanup)
Implement HasTables. Add strings resource and check utilities. Wrap the CloudtTableClient in a testable interface
Add TODOs and more whitespace corrections
Culture invariant dates and other minor tweaks.
Add functional and unit testing to ATS requests. Enhance error handling.
Merge pull request #181 from natemcmaster/ats

Beginnings of a provider for Azure Table Storage.
Rebasing branch 'AzureTableStorage' with dev

Conflicts:
	EntityFramework.sln