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.
Use official xUnit.net bits