BeingOptimistic - An optimistic fix for workitem #1143

There seems to be a disconnect between DSL and the view model/model and when the view model/model is being disposed DSL may pump messages we are not able to handle because view model no longer exists. In this particular case the fix proposed by David seems safe and should fix this particular crash since we are not using the disposed editing context in any upstream caller. Note that we are curing symptoms and the root cause so if we happen to have other event handlers that are being invoked after the view model/model was disposed that rely on model we may still see crashes.
Added annotations to several more tests that are incompatible with the SqlAzureExecutionStrategy
Updated provider agnostic factory to pull default connection string from app.config
00ecef70 079c5769 Microsoft_Data_Entity_Design_Model!Microsoft.Data.Entity.Design.Model.EntityDesignArtifact.GetRootNamespace()+0x18

if some corner cases (in this case if the edmx file contents was removed outside VS) the XDocument representing the edmx file could be either empty or null. When EF Designer tried reloading such a file it would throw a NullReferenceException during validation which would make VS crash. The fix is to check for null and treat the document as invalid.
IndexChangedVSCrashed - There was a bug in the WizardpageDbConfig where we would assume that a connection was always selected in the combo box. However, this was not always the case - one scenario was where the combobox did not have any items and the user went back to the first page and returned to the db config. In this case we would NRE but VS would not crash. Another scenario (which I could not repro myself but found in the crash dumps) was that the SelectedIndexChanged event was fired but the SelectedItem was null (this indicates that the combo box was empty becuase we never add null combo box items and when the combo box is empty the selected item index is -1 and combo box returns null for selected item) which would crash VS. The fix is to not do anything if the selected item is null.
Merge branch 'release-6.1.0'
OnEndEditWeRemoveAV - we overrode OnEndEdit method to raise some events. The code we had could fail for unknown reasons (I believe due to timing/race condition) in which case it would bring down the VS. However it turned out that no one subscribed to the events we wanted to raise so the code was not needed at all - it was always a no-op. The fix is to remove this code.
Merge branch 'release-6.1.0'
Added AddFromAssembly in ConventionsConfiguration to load all conventions in specified assembly automatically in model configuration
Code cleanup
Added protected virtual WriteClassAttributes method to allow custom MigrationCodeGenerator implementations to set class level attributes as described in #1931
PR cleanup
Pull request: Prevent the EDM Wizard from crashing due to issues with a 3rd party DDEX provider
Add support for SatelliteContractVersion for servicing purposes + some bug fixes.
updated two more tests that were failing against sql azure
Fix for getting ps scripts signed as part of the build and making it easier to build/sign nuget packages.
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