Refactoring Northwind and OptimisticConcurrency functional tests

Split Northwind model into separate files and added a context class
Avoiding sharing any state between the contexts that mutate the model or the data
Renamed provider-specific test classes to include the provider name
Cleaning leftover databases
I don't think a fixture is just about state. It is about setting up the _context_ under which tests execute. Creating test collection specific models is a perfect application of fixtures IMHO. 

Re derived contexts, we are _not_ advocating creating provider specific derived contexts. In fact, this is something we will actively discourage and I think this is another reason why we don't want to do it in our FTs.

Again, given all that, and that having a single, consistent approach is desirable, what is the disadvantage of just using fixtures?