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
Remove DbContextConfiguration dependency from StateEntry and related classes

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.

StateEntry now depends on the state manager and its metadata services. StateManager uses data store services through the mechanism introduced in previous commits. The ChangeDetection reactions to property changes through notifications removing a coupling and a potential circular dependency.
Make generated resource helpers public
...and remove reflection-based access to them.
Update default max length values

Resolves #768
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