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
Adding a restriction on the number of rows inserted in a single batch.

Fixes #974
Refactoring BuiltInDataTypesTest and TransactionTest
Made the InMemory provider to match tables by entity type name
Disabled BuiltInDataTypesTest for ATS due to #965

Fixes #789
renaming TraceType to LogLevel
Update .kproj files
Updating to release NuGet.config
Merge branch 'release' into dev
Fixed more FTs that were using the default service provider
Disabled ATS BatchTests and EndToEndTests due to #965
Fixing references used by the performance projects

This fixes issue #991

The TypeLoadException was incorrectly reporting that a method had no body when in reality it was unable to locate one of the dependencies. It's not clear why this exception was reported, but the error stops showing after fixing the project references (both in the csproj and in project.json), followed by a .\build initialize and a clean build of the EntityFramework solution.

The performance projects are now running properly under net45.
Tiny: Rename IsDatabaseCreated on in-memory database to EnsureDatabaseCreated because it doesn't return whether or not it is "created", but rather whether or not it was "created" by this call.
Stop using DbContextConfiguration to get ILoggerFactory

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.

This change makes things that need and ILoggerFactory depend on it in the normal way rather than getting one from DbContextConfiguration.
Make Database facade use more consistent across data stores

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.

There are two main reasons for this change:
- Ensure that the correct provider-specific Database facade is always used even when multiple providers have registered services
- Change the way the ApplyMigrations method is implemented such that, in an upcoming change, it can be decoupled from direct use of DbContextConfiguration.
Remove incomplete UseXxx service methods

These were intended as a form of sugar for replacing services. However, they have not been updated with new services, are used inconsistently, and don't seem to provide real value over just using the normal DI methods. We already know that we need to consider the common extensibility story with some form of sugar, but I don't think this is it, so cleaning this out for now.
Make Database not depend on 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.

This change introduces the idea of registering delegates for dynamic services using the mechanism added recently to the DI abstraction. This allows dynamic services to be depended on in constructors in the normal way. However, since these dynamic services can result in work being done to initialize and build the service the delegates are generally registered to create LazyRef<TService> and so this should be depended on. This allows, for example Database to depend on the current model by depending on LazyRef<IModel> but the model will only be built if the database actually makes use of it.
Renaming performance tests and projects to generate a shorter path.  This compensates for a bug in Coreclr where paths that are to long cause tools to silently fail
changes to ATS proj automatically applied by VS
Make DataStoreConnection not depend on 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.

The main change here is to get the current options by depending on LazyRef<DbContextOptions>. I also needed to update the Redis provider to not depend on scoped services in singleton services.
Merge branch 'Connection1106' into dev
Fix build break
Query: Fixed null ref when using Include with XOrDefault ops and no result