dbtng integration

We should be 100% on wanting to do this. It will vastly simplify the internals of the code, and allow the focus to come off the API as basically a querybuilder. (really, that's most of what it is right now).

forgot the patch started by sdboyer, let's keep this in the queue until a more intrusive patch :-p

If this is intended for drupal.org we need to get approval from the powers that be for dbtng module soon, it has some major drawbacks in certain areas, namely that it opens a second DB connections since the PDO driver can't reuse the mysqli connection.

I'm making a big patch of the sdboyer work at github. Let's end up this work here so we can discuss about the changes before committing.

Pasting commit descriptions:

dbtng integration and entities conversion

- Entities-based approach.
- Initial refactor of the VersioncontrolRepository class to make it properly receive data loaded by the entity controllers via the backend.
- Note about class listings for factory behavior of VersioncontrolBackend
- Update the backends to allow them to alter queries as they are being built by the entity controller.
- Add an optional callback for direct query modification. Note that this potentially screws with caching, so we may not want to retain this approach.
- Initial pseudocode for a VersioncontrolRepository::getLabels() method that utilizes an entity controller stored on the Repository object itself.

I'll be commenting on this patch in the next days.

Let's actually mark this one the duplicate (sorry, given that you just posted that patch here), as that other issue has more information about the approach I'm taking over on github.