EF 6.1: Fix for #1966 - Consolidate annotation indexes and Migrations FK indexes

 Completes all remaining feature work on Indexes:

 - Introduces ForeignKeyIndexConvention, a store model convention which replaces the hard-coded index introduction hack in the differ. Adds back compat. compensation logic to the differ to deal with pre 6.1 indexes.
 - Adds RenameIndexOperation, a new migrations op for index renaming and associated differ detection logic.
 - Various differ and SQL/CLR code gen changes, primarily to support the new op.
 - Enables consistent special character handling for index names. Had to tweak index annotation serialization format slightly.

Work Item: 1966
Merge branch 'master' of https://git01.codeplex.com/entityframework
Merge branch 'master' of https://git01.codeplex.com/entityframework
Added a powershell script that drops all databases on a SQL Azure server except for system databases and sample databases.

Updated after CR feedback
Dexter takes a fall... (2172: FixupReferencesByForeignKeys throws NullReferenceException in EF 6.1.0)

This is a regression caused by a fix that went into 6.1 (Bug 1142) to handle correct fixup when an entity has two FK relationships between the same entities. The underlying problem is that we store a map of FK value to entries that need fixup. But in this case there are actually two identical entries in this map--one for each relationship.

The previous fix handled this by making sure that an entry would not be removed if it was used by another FK. This prevented the entry from being removed when it was still needed.

The new bug is because now the entry may never get removed because on both attempts to remove the other relationship prevents it.

The new solution is to store both the relationship (represented by the RelatedEnd) and the state entry.
Allow MigrateDatabaseToLatestVersion initializer to use context that is being initialized.
Seedy Initialization
f9da23f9965a swapped MigrateDatabaseToLatestVersion`.cs to use the context that initiated initialization. This change ensures that if initialization includes running the Seed method the users context isn't polluted with the data from seeding.
Also swapping the new useSuppliedContext parameter on MigrateDatabaseToLatestVersion`.cs to be false by default since we are going to be shipping this change in a patch release.
Also including a few other minor changes:
 - Tidied up docs on MigrateDatabaseToLatestVersion`.cs constructors
 - Using named parameters where we pass a boolean into MigrateDatabaseToLatestVersion`.cs constructors
 - Renaming _contextForInterception to _usersContext since we now use it for more than just interception
AlsoWorksOnLinux
Fix for issue https://entityframework.codeplex.com/workitem/2168
(Mono on Linux crashes with DbDataReader.GetInt32 when returned value is sql_variant)
MetadataCollection.HandleIdentityChange assumes that the specified item is in the collection, and removes the entry keyed by the initial identity from the case sensitive dictionary, then adds another entry keyed by new identity. Code in EntityTypeBase calls this method on both the Members and KeyMembers collections when the name of a property changes. If the property is not a key property, this results in the property being incorrectly added to the case sensitive dictionary of KeyMembers (luckily the dictionary threshold is 8 so this does not happen unless there are 9 or more key properties, which is not very common)

Added flag to HandleIdentityChange to specify whether or not to do validation of input item and identity. MetadtaCollection calls it with validate = false. Other callers call it with validate = true, in which case the method does not update the collection if the item is not part of it.
ThrowIfYouFeelLikeItOnError: false  (2051: Avoid throwing when assembly version of CLR type changes)

The code that loads CLR types for a model explicitly sets throwOnError to false so that the model load does not fail if a type is missing. This allows Migrations to continue to load a model even after CLR types have changed. However, for some reason if the assembly version is changed then Type.GetType throws a FileLoadException even when throwOnError is false. According to the documentation it can also still throw TargetInvocationException and BadImageFormatException. So the fix is to ignore these exceptions if they are thrown just as we ignore other reasons why the type could not be loaded.

This doesn't prevent the model from having a null CLR type annotation, which for non-Migrations scenarios could result in NullRefException in other parts of the stack. However, this is not different from 6.1 and deciding when and how to throw for a null CLR type is a bigger change that probably doesn't meet the bar right now.
Updating exception message for Unintentional Code First exception.
OnErrorResumeNext - fixing a bug where we would not stop the generate model from database wizard even if an exception was thrown from model generation (fixes issue #2155)
^6(\.\d){1,2}$ => 6.x - We currently ask people to select between Entity Framework 5.0 and Entity Framework 6.0 but if they select EntityFramework 6.0 we install EF 6.1/6.1.1 (workitem #2191). We are changing the resource to show Entity Framework 6.x instead of EntityFramework 6.0 to fix this.
HalfNullHalfEmpty - AssociationTypeMapping returned a collection with a null value for mapping fragments if mapping fragment was not initialized. This later caused an NRE during MSL validation and would eventually break the tooling if the provider schemas were invalid (turned out that it was the case for NuoDb and VistaDb). The fix is to return an empty collection if the mapping fragment has not been set which is what we did before we refactored mapping API.
fix to 2157 - when diffing mapping fragment which condition column has no value, (i.e. row belongs to a particular entity when the column value is null, to a different entity otherwise) we would throw null reference exception when comparing the values of the condition column. Fix is to use static Equals method, rather than its instance version.
Existential crisis... (Fix issues in database existence checking)

For 2113 The issue is that if a user does not have "view any database" permission then a connection to master will succeed but querying sys.databases will not return any results. We therefore conclude that the database doesn't exist--but it actually does, it just can't be seen when connected to master. The solution is to use the db_id() function which will return non null even when the user does not have "view any database". The catch is that db_id() doesn't work on SQL Azure for anything other than the current database, so if db_is() returns 0 we do the query for sys.databases. This should always work on Azure because Azure doesn't have server class securables, which means it is not possible to deny 'view any database' permissions.

For 2068 the SQL Azure issue is that for SQL Azure a user created just in the target database cannot connection to master when using ADO.NET. (Interestingly SQL Management Studio does allow the same credentials to connect to/query master.) This case was actually handled correctly, except that Exists caused context initialization, which in turn sometimes asks for a provider manifest token, which in turn attempts to connect to the database. If the database exists then this works fine. If the database doesn't exist then an attempt is made to connect to master to get the manifest token. This would then throw, resulting in Exists throwing instead for returning false. The fix for this is to use the provider directly to do existence checks rather than initializing the context and using the ObjectContext method.

For 2068 the open connection issue resulted in an attempt to use a master connection when credentials may have been stripped out. The fix is to short-circuit existence checking if the connection is open since opening the connection implies that the database exists.
Removing term 'foo' - it was recently added to Policheck dictionary
Merge branch 'master' of https://git01.codeplex.com/entityframework
Issue 2176: Regression in 6.0.2 -> 6.1: TPH with specified discriminator does not work
Issue 866: Naming a discriminator column "Discriminator" changes mapping behaviour
  Problem:
    When configuring a discriminator named "Discriminator" it is mapped to the column created for the default discriminator. At a later stage the default discriminator is removed resulting in an invalid configuration.
  Solution:
    If a naming conflict is detected uniquify the default discriminator column.

Issue 2161: Regression in 6.0.2 -> 6.1: TPH with only 1 implementation breaking change
  Problem:
    When there there is only one concrete type mapped the discriminator isn't removed because in 6.1 we started mapping the abstract type by default.
  Solution:
    Remove the discriminator condition from the abstract type so it doesn't count for the redundancy check.

Workitems: 866, 2161, 2176
Issue 2214 - EFToolsMsi.wixproj failing to find files from locally packed and installed EntityFramework package. There's a bug in nuget. This works around that bug by copying only the non-symbols nupkgs to another directory before installing from them.