Beginning of Metadata layer implementation.

- Implemented MsgRequest, MsgResponse, MsgRequestBatch and
  MsgResponseBatch messages to wrap around single / multiple server
  update or query requests / responses.
- Implemented Request and Response base classes used for encapsulating
  file system operations (and their responses). Defined supported
  operations and unique identifiers for each and started implementation
  of the request classes for some of them.
- Implemented permission checks and serialisation in AuthedUser
- Renamed serialisation methods write_to_fd and read_from_fd to
  write_to and read_from
- Added BaseStream abstract class to allow non-templetized
  serialisation methods.
- Implemented String wrapper around ::std::string for serialisation
  purposes.
- Added support for computing SHA1 sums.
- Fixed some instances std::{type} to ::std::{type}.
Proper cluster coordination.

- Started using ZooKeeper for cluster coordination.

- Upon starting, each BDFS server registers with ZooKeeper, creates
  nodes identifying its ip address, port and served or replicated
  key ranges as well as its status (whether or not it is serving
  client traffic). Once registered, it attempts to elect itself as
  cluster coordinator.

  A cluster coordinator has the responsibility of reacting to new
  machines joining the cluster or existing machines leaving the
  cluster via failures or otherwise.

  If no coordinator exists when one server boots, it declares itself
  coordinator, otherwise it fetches the machine id of the coordinator
  from ZooKeeper.

  All machines register a watch on their status node to detect when the
  coordinator pauses / resumes them.

  The coordinator registers watches on the root PRESENCE node in order
  to track changes to its children (and thereby track new and old
  machines).

  The coordinator gathers information from all registered machines and
  publishes a coherent picture of the partitioned key space in the SERVER
  GROUPS node which all nodes then start watching.

- Updates to the SERVER GROUPS node are propagated to all machines
  within the cluster which then fetch the new value from ZooKeeper to
  obtain a consistent image of which machines serve and replicate which
  parts of the key space in each of the three layers.

  The Directory, File and Data groups are each stored within each
  machine's state. For each group we maintain information about all
  machines that are part of the group as well as store information about
  the persistent connections between these. Upon an update, these
  connections are transfered to the new server groups, the pointers to
  the server group data structures are swapped, the no longer needed
  connections are closed and the old data strctures are deleted.

- Changes to server groups are now done under the global state_mutex
  rather than relying on individual write mutexes for each server group.
  This was done in order to allow implementing server group changes by
  simply swapping pointers rather than implementing more complicated
  logic.

- Persistent connections between machines within the Directory and
  File layers are now kept opened.

- Added ConditionVariable to the concurrency module.

- Implemented ability to pause server processing while performing
  cluster initialisation or failure recovery.

  This is done by maintaining a server paused flag within the server
  state (which is coordinated by ZooKeeper). When events occur, the
  flag is checked and if it is set, the thread is blocked until the
  flag is unset. Once the server is unpaused, all blocked threads are
  signaled and behaviour can resume normally.

- Got rid of legacy read_from_fd and write_to_fd methods from
  server_host and server_group

- Moved bdfs_client_state_t from protocol/message to core/bdfs_server