Implementation of strong consistency using locks

[peterzeller]

This PR adds support for strongly consistent (serializable) transactions by using Locks.

Current status:

There is still one failing test case: The cluster_failure_test_2 sometimes fails. The test crashes a node holding the locks and then restarts it after some time. After the restart, another DC should be able to get the locks again, but the crashed DC sometimes is not able to read its CRDT state after restarting. I still have to debug this case - I am not yet sure if this is a problem with the lock implementation or a general problem in Antidote. Unfortunately, the bug occurs less frequently the more log messages I add for debugging.

The rest of the implementation should be working.

Documentation is available in https://github.com/AntidoteDB/antidote/blob/strong-consistency-3/src/antidote_locks.md

[bieniusa]

From the documentation:

The call to start_transaction may fail if Antidote is unable to acquire the lock.

What message is then sent to the client?

[albsch]

Using -erl_args -hidden causes every suite to restart and reconnect every node. This causes an infinite request log_read loop in the clocksi_SUITE, which indicates either a problem with the hidden parameter or an inter-dc communication problem (which goes back even before my inter-dc simpliification).