fixes to include-related bugs - 925 and 926

Bug #925 - include fails for entities with composite keys
Root cause of the issue is that at one point during query generation we create join predicate expressions using Expression.And operator, but later in the pipeline we expect AndAlso operator.
Fix it to construct the initial expression using AndAlso operators.

Bug #926 - invalid sql generated when performing query with include
Root cause of the issue is that we build the comparison for join predicate incorrectly, swapping the column names.
Fix it to swap the names to the correct order.

CR: Andrew
Merge branch 'release' into dev
Query: Fix for #871 - Query should use provider-specific table names, column names, etc.

- Table/schema names were already handled by @ajcvickers
- Enabled correct column name handling
Testing around and some tweaks to EF DI/options infrastructure

Or: What's on the end of the stick ,Vic?

This is mostly testing making use of the new patterns for service provider and options injection, including:
- Multiple context types
- Multiple providers
- Constructor injection of OptionsContext
- Readining config (indrectly) from IConfiguration or inline

Also, added the ability to auto-configure a provider if it is the only provider regsitered, which also paves the way for auto-configuring from file-based configuration only.
Update AddEntityFramework to ensure low-level required services are available

Or: It's our collection and we'll look if we want to...

Issue #890

These services are normally setup by the app environment in an ASP vNext app, but are not setup when we create the service provider or the service provider is being setup in some other app environment. This changes makes sure that however the service provider is used, then these required services are available just like all other services required by EF to run correctly.
Honor schema in SQL query (Issue #931)

Or: Eating the same half of the pie twice

The issue was that even though the table expression has the correct schema the SQL generation was not using it.
Fix #906: Some queries in MonsterFixupTest throw InvalidCastException

Problem: Nullable enums were not being handled correctly in EntityMaterializerSource and EntityQueryModelVisitor.
Solution: Centralize logic for ReadValue expression creation. Add support for enums.
Removing CodeAnalysis suppressions from TaskExtensions
add gears of war model to tests
Allow data store selection to happen in OnConfiguring (Issue #932)

Or: Attack of the Semi-Deep-Memberwise-Copies

Previously the common scenario for DbContextOptions was that a new object would be created for each context instance. This allowed it to be mutated in OnConfiguring such that, for example, a different data store could be selected each time. There was also the case where DbContextOptions was put into DI or passed to the constructor, in which case OnConfiguring would be called once and the options would be locked.

The recent changes to options means that the common case is now for DbContextOptions to be in DI. This means that this single object is shared by all context instance created by the app. This results in two problems:
* The locking now happens almost always, effectively making it impossible to dynamically select options in OnConfiguring
* The dynamic selection is not thread safe, but it can be executed by multuple threads all sharing the single object.

The solution is to clone DbContextOptions before passing it to OnConfiguring. This means that all context instance can share common options and also can dynamically change those options in OnConfiguring without impacting other instances. This restores the previous functionality, removes the thread safety issue in the normal path, and also means that locking is no longer required.
Remove original connection string resolver

Or: Is that a name in your pocket, or are you just happy to be a connection string?

Removing the original connection resolution code which relied on IConfiguration being in the DI container.