[policy, no patch] Make default SQL drivers MySQL specific

As I argued in the PostgreSQL issue:

With CMI most of the simple tables are banished from core.

What we have are sophisticated subsystems that need storage specific drivers. And most of those drivers need PostgreSQL specific code. With 9.3 and 9.4 especially, the ability to store and query JSON efficiently while retaining the capability to JOIN makes PostgreSQL potentially a compelling offering for entity storage. Trees could use much more efficient encodings if the table can have functions in the indexes. So on, so on.

So yeah, we have SQL code that is supposed to be cross platform but the test fails prove they are not and there is no need for them to be now that everything is pluggable. We also squander the opportunity to use MySQL specific features because of this polite fiction of being cross SQL compatible. There's no need for that anymore, if you want to user another DB, SQL or not just replace all the storage related services.

David Strauss concurs:

An example is variable_set(), which we've had to replace in the last week with some MySQL/MariaDB-specific code for some customers to avoid deadlocks caused by the portable merge-query code. Yes, it's broken to call variable_set() so much in the first place, but it could be any other function designed for use on general, public pages.

The only way for us to make the solution truly DB-TNG friendly would be to write a custom merge driver for MySQL/MariaDB that picks a strategy (SELECT...FOR UPDATE or ON DUPLICATE KEY UPDATE) based on whether the merge query criteria are equivalent to the table's primary key. Even figuring out the ideal strategy substantially slows down the code path because the merge criteria have to be compared with the schema.

We could also have primary key vs. flexible merge queries available as distinct query types, but then we'd be preferring MySQL/MariaDB in the abstraction layer -- which is better, I think, than what we're doing right now by being skittish about treating MySQL/MariaDB as our prime target.