Commands: Only use ambient context on same project
String resource tidy up
* Add info about installing KVM to use migrations commands to Database Error Page
* Removing 'refresh the page' <a> which was broken
* Fixing typos (all string run thru spell check - thought I had done this but evidently not)
* Fixing package description for SQL Server package
Cleanup interaction of DbSet and DbContextConfiguration

This is part of Issue #641 which is about cleaning up the use of DbContextConfiguration. DbContextConfiguration is intended to help resolve dynamic services--that is, services for which the actual type/instance of service to use depends on the current context configuration. However, it has gradually spread throughout the code as a general purpose service locator. This causes dependencies to be hidden and creates a lot of coupling to DbContextConfiguration throughout the code, so I am making a set of changes to help fix this.

In this case the DbSet needs to have access to DbContextConfiguration, through the context, because sets are created eagerly before the scoped service provider is created, but are then initialized lazily in the scope the first time they are used.
Making Ignore behave the same independently of the order relative to other configuration.

If a property or entity was added and ignored explicitly an exception will be thrown.
If a property or entity was added and ignored through conventions or data annotations the property will be present on the entity.
If a property is ignored and removed after conventions or data annotations added keys, foreign keys or indexes referencing it they will be removed as well.
The same applies to entity types and foreign keys referencing them.
Commands: Block Apply-Migration on Store Apps
Removing Microsoft.AspNet.Diagnostics.Entity from this repo
There is a corresponding pull request to add it to the Diagnostics repo
Provider specific migrations part 1:
1. Updated migration operations pre processors to be able to run at the very end of Diff instead of the begining of SQL generation. This will result in full sequences of migration operations specific to the provider.
2. Removed DatabaseModelModifier from production code.
3. Updated the MigrationOperationSqlGenerator to use the target DatabaseModel instead of one cloned from source that is updated as the operations are processed.
4. Updated tests. Removed some scenarios that were possible before because the migration operations could be altered  by the user before being passed to pre-processor, but are not possible anymore.
NOTE: The name PreProcessor should probably change. Because the input into the PreProcessor comes from the differ without being altered by the user, they can be simplified and even integrated into the provider specific diff logic, but I would prefer to do that a bit later, in order to avoid large changesets which are difficult to review.
Part3