Remove supports_transaction() and the need for it. Refactor to create a Rabbit Connection class.

* Go back to not checking supports_transaction() before committing. If we're not in a transaction, nothing bad's going to happen. If a connection doesn't support transactions, commit() is a no-op. Delete supports_transactions(), which is now unused.
* Create a Rabbit Connection object to provide no-op commit() and rollback() methods so we can call that stuff unconditionally from the transaction executor. Adjust the calling code in Rabbit crashstorage to burrow into the Connection, pull out a channel, and use it. Not very happy with this half-abstracted architecture, but it was that way when I found it. We can fix it another day.
Remove some methods from classes where they shouldn't be.

Somehow, some ConnectionContext-like methods made their way onto Connections. Nobody ever calls them there, so goodbye.
rollback() unconditionally in the transaction executor.

If we're not in a transaction, nothing bad's going to happen. PG gives a NOTICE in the case of rollbacks and a WARNING in the case of commits, and we've been doing commits unconditionally forever on master.

Delete in_transaction(), which becomes unused.

Delete a test that was just making sure we didn't roll back when in a transaction. I don't think it asserts anything else useful (a docstring would have been nice here); test_rollback_transaction_exceptions_with_postgres() already makes sure we roll back on exception.

Update a test's expected rollback count; rollback always happens now, harmlessly.
Have a separate internal cache for each Rabbit crash storage.

There's no reason to share one across instances. Since they might leak anyway, let's at least let them go out of scope when an instance is disposed of. (Not sure when or if that ever happens.)
Merge pull request #1251 from erikrose/merge-rabbitmq

Get merge-rabbitmq branch ready to merge with master.