Paul Daniels or Penn & Teller? (Remove relationship APIs from BasicModelBuilder)

We decided last week that we should have a basic model builder that would map closely to the underlying metadata and would not use any conventions together with the more traditional model builder that has sugar API and makes use of conventions. The relationship APIs (OneToMany, OneToOne, etc.) cannot function without conventions and so should live only on the convention-based builder. In doing this the inheritance, overrides, and "new" classes and methods became increasingly difficult to handle, so most of this change is a refactoring  which hopefully makes things easier to handle and evolve.

Some possible approaches I looked into were:
- Deriving the convention builder from the basic builder. This didn't work very well because of the need for changing of types in the sub-builders, resulting in a lot of "new" methods. It also means we can add things to the convention API, but cannot remove things. For example, currently the convention API has both the sugar relationship APIs and the lower-level ForeignKey API, but we may choose to not expose the ForeignKey API.
- Also, we currently derive the generic builders from the non-generic builders. This works quite well, although the need for a base class makes it harder to work with, and this leaks into the code for extension methods which have quite involved generic type definitions using the base types.

The best approach I have been able to come up with makes use of a couple of patterns that have worked well in the past:
- Split the actual logic of model building into implementation classes. These are not specific to the convention or basic builders which can then make use of any functionality that makes sense. This allows the public API to be decoupled from the implementation so that we can present the public API that we want while keeping the logic in a single place and factored appropriately for the implementation. Traditionally these implementations would have been internal, but I have made them public in keeping with the EF7 philosophy, just in an internal namespace.
- The actual basic and convention builders are now separate and don't derive from each other. This does result in some code duplication, but it is specifically API code and not implementation code, and it allows for flexibility in the two APIs as described above.
- Conversion operators between the two types of builders are easy to create and I added them at the top-level, but we should discuss whether these are really useful.
- I wanted to make API extensions relatively easy to write and also allow a single extension to be used for both the basic and conventional builders. To facilitate this there are interfaces for each of the builders that can be targeted by extension methods. These interfaces provide easy access to the metadata item being targeted (e.g. EntityType), the model, and the Annotation API. This allows extensions to be written in a very similar way to the core fluent API. It does not provide direct access to all the fluent methods of the builders because doing so tends to make the interface/type definitions overly complex. Also, the fluent methods available are different for the different builders. If the fluent methods need to be used it is still possible to write specific extension methods for specific builders.
Cleanup project.json files
More improvements to the async query pipeline.
Adds more queryable ext. methods
SQLiteMigrationOperationPreProcessor:

The operations are classified as follows:

1. CreateTable
2. Table subordinate operations (involve ALTER TABLE ...). The subordinates are divided into: renames (RenameTable, MoveTable), supported (AddColumn) and unsupported (others). The renames are supported operations.
3. Other operations (AddIndex, CreateIndex, etc), including DropTableOperation.

The operation sequence is handled as follows:

1. The table operations are grouped as encountered (except DropTable). They are pending (not processed).
2. When encountering a DropTable, or a non-table operation, the pending operations are processed first, then the current operation.
3. When getting the result Statements the pending operations are processed before return.

There are 3 types of group handlers that store pending operations, each identified by the name of the table it operates on.

1. A CreateTableHandler is started when visiting a CreateTable operation.
2. An AlterTableHandler is started when visiting a supported subordinate operation on a table not associated with a handler.
3. A RebuildTableHandler is started when visiting an unsupported subordinate operation on a table not associated with a handler.

Note:
An AlterTableHandler is promoted to RebuildTableHandler if an unsupported subordinate operation on the corresponding table is encountered.

The pending operations are processed by each handler as follows:

1. context.Generator.Database is cloned and stored into context.Database
1. CreateTableHandler updates context.Database with all operations in the group, then generates a CreateTable operation for the up-to-date table.
2. AlterTableHandler simply returns the operations in the group.
3. RebuildTableHandler updates context.Database with all operations in the group, then generates a DropTable operation with the initial table name followed by a CreateTable operation for the up-to-date table. In the future this will include an operation for copying data (including rename if table name did not change)
4. The operations returned by handlers are processed, context.Generator.Database is updated, and the handlers removed.

Note:
When the RenameTable and MoveTable operations are processed the TableName associated with the corresponding handler is updated.
Improving failed query test diagnostics
"Microsoft ADO.NET Entity Framework Feature Community Technology Preview 4"  (Use full CLR name for entity name)

As per design meeting notes June 5: https://github.com/aspnet/EntityFramework/wiki/Entity-Framework-Design-Meeting-Notes-June-5,-2014#fluent-api

Also added a SimpleName property which is used for:
- Convention matching and FK naming
- The default table Name

Did additional refactoring to remove NamedMetadataBase because
- It was not adding value
- Changed EntityType to not store the CLR name but just get it from the type
- Introduced PropertyBase which is the concrete implementation of the existing IPropertyBase and will be needed to address navigation properties in the fluent API for annotations, etc.
Unicornopoly: The Fast-Dealing Property Trading Game... (Update Property fluent API to match design meeting notes)

This change updates the Property method to match the design meeting notes from https://github.com/aspnet/EntityFramework/wiki/Entity-Framework-Design-Meeting-Notes-June-5,-2014#fluent-api

Specificly:
- Remove shadow state and concurreny parameters and add fluent methods instead
- Make string overloads create shadow properties by default unless the property is already known
Disabling groupby min tests
Merge branch 'dev' of github.com:aspnet/EntityFramework into dev
Code cleanup
Use external service provider for in-memory query fixture
Target wpa81
Tweaked relational query provider enumerators
Re-enabling problematic groupby tests
Revert "Re-enabling problematic groupby tests"

This reverts commit e04559811cf7c76030d86568de522bf94b776634.
Implemented the Northwind tests for Redis plus some tidying up (e.g. removed
BaseClassFixture since not really using it).
Updating to make UnderlyingType a metadata property
DbContext.Add should use sync path
Format JSON documents