Make the provider extensible

Start by reading SqlDesignTime.fs around lines 52 and 354, then compare the linked commit and transactional-update example to the current provider API. The issue needs an agreed extensibility design before implementation; done would mean a specified, documented extension API that supports the proposed entity and transaction scenarios without breaking the current API.

I was trying to create multiple entities that have foreign key dependencies between them in a single transaction, which is not currently possible. While trying to address the problem I realized that the provider could be of much more value if it allowed the programmer to extend it. In other words if a programmer could use the types extracted from the database to add more features to the provider such as transnational creation of entities. To test my hypothesis, I modified the provider to allow extensions: https://github.com/netogallo/SQLProvider/commit/0204f4db8c8e9210b8e0df728eb0b6571c55e77f with that in place I created an example of how it can be extended to have transactional updates: https://gist.github.com/netogallo/6c85782c89544a48552c . Both of theese examples are very raw and would need improvement if they were going to be part of the provider. I just created them to explain my ideas.

Now concretely speaking, how do I want to extend the provider:

1. The create methods of entities can accept entities as arguments where we currently accept foreign keys (SqlDesignTime.fs:354). My extension allows that but I have to change the type so it is the specific entity referenced by the relation (not any SqlEntity) but that would require more time and didn't wanna complicate it too much for a simple proposal. The referenced entities are stored differently in order to allow the entity to see the updates that happen in the referenced entity. This is what allows the transactional create to be possible since I can create the entities in the right order.

2. Define a super-class for the "serviceType" (SqlDesignTime.fs:52). I made SqlContext the super class in the example but I think it sould be a special class designed to provide a nice API to access the information of the provider in a useful and safe way for easier extensibility.Maybe create sub-classes for all the SQL drivers so one could extend the provider with MSSQL specific extensions w/o having to extend every provider.

3. The super-class for the "serviceType" should provide good methods to extend it's functionality. For example, the functions that are used to create insert/delete/update comands could be exposed and maybe also expose a method that takes a function (that takes a connection as an argument as an argument) and executes it inside an SqlTransaction? That way one can easily add more functionality to the type providers w/o much trouble. (With my example it is still tedious to do this, but you can).

Allowing the provider to be extended also allows it to be more modular. Ie. the basic provider infrastructure could be provided in one package and then database specific packages with the advanced functionality could be created separately so new features can be added to specific drivers w/o having to update drivers for all databases.

I volunteer to implement these changes properly, but I need advice and opinons about the proposal to know what would be the best way to make the provider extensible. On my sample, I focused on adding extensible w/o breaking the current API. Look forward for feedback.