Bug 2597: Batch modification operations in TransactionProxy

Bug 2597: Batch modification operations in TransactionProxy

Modified TransactionContextImpl to batch write, merge, delete modification
operations into a single BatchedModifications message and send the batch when a
count threshold is reached.

Instead of using the current WriteData, MergeData, DeleteData message classes
in BatchedModifications, I reused the Modification classes that are used
as the payload for peristence and replication. BatchedModifications
derives from MutableCompositeModification.

The ShardWriteTransaction now simply transfers the Modification
instances in the BatchedModifications instance to its internal
MutableCompositeModification and applies the Modifications to its
transaction.

The Modification classes were refactored a little wrt to versioning.
The Write/Merge/DeleteModifications no longer read/write the version
from the stream. The version is read/written by MutableCompositeModification
so it's redundant to also do so in the data Modification classes.

The WriteData, MergeData, DeleteData and associated reply classes were
deprecated. I did refactor them a little (along with ReadDataReply) as I
was originally going to use them. The VersionedSerializableMessage interface
was removed as I realized it makes more sense to pass the version in the WriteData,
MergeData, DeleteData constructors instead of passing the version via
toSerializable. This made it easier in TransactionContextImpl to transition it
to use BatchedModifications. I created a VersionedExternalizableMessage
base class that reads/write the version.

To handle backwards compatibility with Helium, I derived a
LegacyTransactionContextImpl class from TransactionContextImpl that overrides
writeData, mergeData and deleteData to send WriteData, MergeData,
DeleteData messages. TransactionProxy creates this instance if the
remote tx versions is < Lithium version.

Change-Id: I28df1f89e97667eaca114b991355a6e9d0160a59
Signed-off-by: tpantelis <tpanteli@brocade.com>