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.
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
Adding cross store FTs
Fixing filtering in AtsTestFramework
Make DataStore 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.
Improve generated resources classes

Changes:
* Remove properties for resources with arguments
* Remove methods for resources without arguments
* Remove "Format" from method names
Fixing setup for one performance test and marking two others that currently fail
Make BatchExecutor, Migrator, and HistoryRepository 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.
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.
Provider specific migrations part 2:
1. Modified CreateSequenceMigration and CreateTableMigration to contain fields similar to Sequence and Table instead of referencing these objects. This enables the removal to the relational model.
2. Updated related code and unit tests.
Test fix
Create abstraction for state entry metadata services

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.

A lot of the services used by a StateEntry are about accessing and using metadata related to the entity type. These have been abstracted out so that the StateEntry does not need to use the DbContextConfiguration service locator for these things.
Adding API for ignoring a property
Decouple value generation from DbContextConfiguration and state entries

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.

Value generation is special in that it needs to be a singleton service such that values span context scopes for things like the in-memory provider and for management of sequence blocks. However, the generation process may sometimes need to make use of the current data store, and hence the current context scope. This means that a value generator cannot just depend on any scoped data service that it needs because it is itself a singleton. Therefore, the generation methods are passed the current data store services such that they can be used if necessary.

In addition, since the state entry was no longer being used to get access to the current scope it meant that decoupling from the state entry was possible. This decoupling in general made the code simpler and made more apparent the fact that the ForeignKeyValueGenerator wasn't really a value generator and hence no longer tries to be one and is handled separately. This is cleaner especially since it was being partially handled separately anyway.
Changing the uses of BasicModelBuilder to ModelBuilder in FTs