Fix rollback being attempted on no transaction because commit already rolled it back

[lsunsi]

Problem

The issue is better described in the linked issue.
Fixes #252.

Solution

I think the commit succeeding and failing specifically for SerializationError means the same for the transaction manager: that it should adjust it's internal state and nothing else.

How I found out about the issue

I'm running diesel_async on a highly concurrent web-server. On 0.5.x I saw that some transactions were left open on the transaction manager (in memory state) so that the next transaction starting would cause a failure (AlreadyInTransaction).

0.6.x fixed that guaranteeing that serialization failures on commit would generate a rollback. No AlreadyInTransaction was ever seen again, but then we started getting "there is no transaction in progress" from PostgreSQL.

My reasoning is that on 0.5.x, the connection behavior was correct but the in-memory state was not.
Then in 0.6.x, the connection behavior is correct, the in-memory was also correct, but an extra ROLLBACK command was issued, which is incorrect behavior.

Then I think this PR leaves things in a correct state, as the test shows.

Shortcomings

I'm not sure about the effect of this PR on nested transaction, especially since I don't use them and don't know much about them. Maybe someone can shed some light if this change is enough or more work needs to be done to avoid breakage in these scenarios.

cc @lochetti