BaseTransaction should define at most one commit/rollback and multiple store aspect

Nobody has claimed this yet.

The BaseTransaction interface and AbstractStoreTransaction partial implementation discuss transactions at the backend level but do not explicitly state that transactions can contain mutations for multiple stores. I was extremely surprised to see that I was able to switch from supporting one store in DynamoDbStoreTransaction to [supporting multiple stores](https://github.com/awslabs/dynamodb-janusgraph-storage-backend/pull/231) with [no new test failures](https://travis-ci.org/awslabs/dynamodb-janusgraph-storage-backend/builds/259093219?utm_source=github_status&utm_medium=notification). I think our AbstractStoreTransaction implementation is naive and we need more cross-store testing at the KCV test layer or graph store test layer. Issues reported on SO about [locks not being released](https://stackoverflow.com/questions/42090616/titan-dynamodb-doesnt-release-all-acquired-locks-on-commit-via-gremlin/43742619#43742619) may have been caught by K(C)VStore tests had we tested this cross-store aspect of locking.

Start by reading the BaseTransaction interface and AbstractStoreTransaction partial implementation, then inspect the K(C)VStore tests and graph store test layer. Define the expected single-commit/single-rollback behavior for transactions spanning multiple stores and add cross-store locking coverage; done means the tests catch failures such as unreleased locks.

Written by the indexing model from the issue text.