Add transaction abstraction

How would people feel about adopting the semantics of PressFlow Transaction as the abstraction layer? For PHP 4, it could be a dummy object that doesn't run transactions. So, functional transactions would requires PHP 5 + MySQL with InnoDB or PHP 5 + PostgreSQL. Anything less would still run, just without transactions.

The semantics of PressFlow transaction are particularly elegant because destructors handle COMMITs and ROLLBACKs. It prevents stray transactions from lingering.

Here's a rough patch versus HEAD. I'm trying to be conservatively compatible with PHP 4, at least ot avoid errors.

By PHP 4 "compatible," I mean that functions using this object shouldn't cause errors in PHP 4.

Here's an updated patch. If this gets committed, I'll create a new issue that adds support to the rest of Drupal core for using these transactions. The ugliness of the code is largely a result of complying with PHP 4 parser rules so this class doesn't create an error.

Running a function's operations (and all encapsulated operations) in a transaction simply requires adding the following to the top of the function:

  $txn = new db_transaction();

When $txn leaves scope, PHP takes care of the ending the transaction.

Using classes isn't typical Drupal style. Here's why we should make an exception:
* A class provides nice encapsulation for detecting nested transactions. Once Drupal drops PHP 4 support, the current global variables will become static class members. Using a class today prevents unnecessary API changes in the future.
* Exploiting object scope to end transactions prevents runaway transactions from happening. If we require a call to db_transaction_commit() or something similar, some code, somewhere will forget to call it and cause the most confusing issues you've ever debugged. (Changes will appear to take effect while the page runs, but nothing will permanently get saved to the database.)
* Using object scope as the transaction controller encourages good programming style. Instead of starting and ending transactions all over a function, developers will create new functions that encapsulate the transactional operations. This is how critical sections are isolated in Java, and it's very easy to read and debug.

Fixed some comments.

Why we should accept degraded support for PHP 4:
* The support degrades gracefully. Drupal doesn't use transactions right now, and the degraded PHP 4 behavior of this patch just continues using no transactions.
* We can't use object scope as the transaction model and support PHP 4.
* We're trying to encourage users to move to PHP 5. Transaction support provides a good reason for user to consider the switch.

To further add to the list in #6:
* Using object scope allows functions to return values more easily. If we require a call to something like db_transaction_commit(), functions will have to store a DB result to a temporary variable, end the transaction, and then return the temporary variable.