Fix for CodePlex 2579: Thread using Migrations can cause other threads to use wrong connection

The root of the problem is that using DbMigrator causes change to app domain state through use of a static dictionary in DbContextInfo. This change in state can cause a context instance of a given type to get the wrong connection when a migrator is being used with that context type. In other words, the migrator changes static state so that any context instance of a given type used in the app domain will get the connection intended to be used for migrations.

In the repro that state was not being cleaned up; the previous fix for this issue caused it to be cleaned up and so the other context in the repro code started getting the correct connection again. However, the code still transitions through this change in app domain state. So if some thread is using a migrator and some other thread starts a query while the migration is going on, then that second thread will use the wrong connection and return wrong data. I suspect that this is what is happening in the production system with the "long running queries", etc.

The fix is to remove the static dictionary and set the context info for the current thread instead. This is similar to the code we have in EF7 for getting the service provider into the constructor without passing it--the issue is essentially the same since the context info is needed in the context constructor and yet is not passed into the constructor. I believe that thread static is fine here because there are no opportunities for async calls between setting the thread static and reading of the value. See https://entityframework.codeplex.com/workitem/1552 for the original issue.
Fix for issue 2590. Revert changeset 6f4a59148c5c. I.e. remove interceptor that turned on DBCC 9481 flag. The flag could only be used by admin users and our queries have changed so the flag should no longer be necessary.
Updating master branch version number to 6.1.3-alpha1 after creating release-6.1.2 branch.