TheHumberBridge (Bridging the gap between DbConfiguration and Interception)

This change creates a bridge between interception and the code-based configuration. In general, interceptors can be added and removed dynamically at any time, whereas code-based configuration is intended to be unchanging for the application. However, if you want to setup an interceptor that is added at application start and never removed then it makes sense to think of this as code-based configuration. There is now a DbConfiguration.AddInterceptor method to allow this.

The implementation required that a GetServices method be added to IDbDependencyResolver. This method returns all services that satisfy a given type and key combination. This means that many IDbInterceptors can be registered and returned by either adding them in DbConfiguration or by any other IDbDependencyResolver mechanism, including an IoC container. These interceptors are read once as EF is initializing and are registered just as if they had been registered directly on Interception.
Issue 808 - Strongly typed nested projections
Converting built-in configuration conventions to lightweight conventions

RequiredNavigationPropertyAttributeConvention, KeyAttributeConvention and ModelNamespaceConvention are using internal API since at this time there are no other known compelling scenarios that would need this API to be public.
CodePlex #1126: Changed function that validates a parameter name to use a regular expression pattern that matches Unicode names
CodePlex #362: Added condition to match the association type corresponding to the foreign key when updating the PrincipalTable of a ForeignKeyBuilder.
Migrations: Implementation of feature #770 - Migrations: Add idempotent -Script option

Enhances -Script so that if SourceMigration == $InitialDatabase, then the resulting script can be applied to a target database of any version.

- Adds a new operation type: UpdateDatabaseOperation, which aggregates the full list of migrations required to take an empty database to the latest version. This allows SQL generators to generate "safe" SQL by first probing for the current version of the target database and then executing only the operations that are pending. The operation also contains a list of query command trees representing the history table probing queries required to correctly determine the current version of the database. The scripting decorator will turn regular migrations ops into an UpdateDatabase op when SourceMigration == "0"
- Tweaked SqlGenerator to track the list of tables being targeted by generated query.
- Changed SqlCeMigrationSqlGenerator so that all generated statements are batch terminated - CE only ever supports a single statement per batch and so this makes CE scripts more likely to work with client tools.
- Fixed a minor issue in query command tree interception.
- Added CreateDiscoveryQueryTrees to HistoryRepository to support scripting of history table probing

Work Item: 770
Updates to TptMappingTests for consistency with similar tests
Migrations: Fix for #1194 - Performance: InitializeDatabase regressed by changeset 1911dc7cef21

Solution: Make creation of ModificationCommandTreeGenerator lazy so as to not incur the overhead of building the dynamic update model unless we need it.

Work Item: 1194
MigrationsCeleryStrikesAgain (Provide more useful info when older initializers are used and Migrations is enabled)

This change alters the way database initializers behave when it is detected that Migrations is enabled, especially when the database does not exist. The problem is that if Migrations is enabled but then one of the older initializers is used we decided that it should not create the database since, in general, Migrations should be used for this.

There were two problems with what we had before:
- If the user does Enable-Migrations and then hits F5 we want a useful message. As the code was before we just failed in a relatively obscure way because the database doesn't exist.
- There was a bug that meant the Drop... initializers would drop the database and then fail in an obscure way because the database does not exist.

The fix is to throw with a useful message if we know that the database doesn't exist but Migrations is enabled. Specifically, if a Migrations configuration is discovered, then:
 - If the database doesn't exist, then throw informing user to use Migrations to create the database
 - If the database exists but the model is out-of-date, then throw informing the user that the model is stale and Migrations should be used to update it. (This is the current behavior for CreateDatabaseIfNotExists anyway, and now makes sense for DropCreateDatabaseIfModelChanges as well.)
 - If the database exists and is up-to-date, then do nothing.
 - If the database exists but contains no MigrationHistory table, then do nothing (which is current behavior) except for DropCreateDatabaseIfModelChanges where it is expected that there will be metadata so we throw as before.

Note that "database exists" means that the database both exists and contains some table that can be mapped to an entity type. In other words, empty databases are considered databases that don't exist.

CreateDatabase also has the behavior that it will throw if Migrations is configured, which is the behavior introduced some time ago. This makes sense because DbMigrator should be used to create the database in this scenario.

Note that the change tries to make sure that an actual Exists check on the database does not happen more often than it did previously.
Runtime: 3 fixes:

 #1154 - SQL CE :: when trying to scaffold a migration that uses MapToStoredProcedures on SQL CE, we create migration with empty body, rather than throwing earlier

 Solution: Remove the body argument check from the create/alter procedure migrations fluent APIs.

 #934 - CodeFirst: Each call to Map/MapToStoredProcedures overrides the previous ones, even if they were mutually exclusive

 Solution: Added missing null checks from the config merge method.

 #1222 - Infra: Enable build against SQL Express v.next

 Solution: Reworked some asserts that were dependent on 2012.

Work Items: 1154, 934, 1222