Started implementation of an interactive BDFS client.

- Attempt to reuse most of the same architecture of the server with
  requests and responses being handled by worker threads. Should allow
  to test load under high concurrency without significant changes to the
  code.
- Cluster composition is read from ZooKeeper upon client bootup and a
  watch is set up for changes just as for servers.
- Moved code around such that the big monolothic main.cpp was split into
  separate files under server/ and such that executables are now under
  bin/.
- Add zookeeper address as a required argument when booting up the
  server.
- Fix race condition between cluster coordinator determining a new node
  has joined and it attempting to resume it before it actually created
  its paused node.
Defined all requests for metadata layer API.

- Went through and established what each request needs in terms of
  arguments, where each would be routed and how each would be
  implemented. As a result, changes were made to the list of internal
  only requests which are there to facilitate implementation of the
  public API.
- Wrapped around the three ServerGroups that appeared in multiple
  places togehter into one single BDFSCluster.
- Added a utility class for dealing with paths.
Infrastructure for replying to client requests.

Introduced the idea of RequestProcessors which basically split up a
the actions that need to be performed in order to fulfill a request into
different phases such that whenever an action occurs which would need to
block the current worker thread the request processor yields control, is
added into a waiting queue and then woken up when it is ready to
unblock.

For example, consider the example of an MkDirRequest. First of all, we
need to launch a series of parallel requests in order to check whether
the user has permissions to access the parent directory in which the new
directory should be created. Once all of these requests have been
responded to and we have confirmed the user has the required permissions,
we need to create a new DirectoryMetadata and DirectoryContents node on
the current host and then launch another request to the host handling
the parent directory in order to link the newly created directory to the
parent. Once that request has been responded to, only then can we
reply to the client. RequestProcessors allow us to continue employing a
light-weight asynchronous approach to the work that needs to be
performed rather than having to use synchronous blocking semantics which
would require spawning a thread per request.

Implementation wise, this meant augmenting the bdfs_client_state_t
datastructure to maintain a mapping between issued request ids and the
request processor which is waiting for a response to that request as
well as a queue of request processors that are now unblocked. In
addition, we maintain a mapping between received request ids for batched
requests and a vector of batched responses which allows us to have
separate processors for each independent request in a batch and still
issue a batched response once each individual request has been
processed.

In addition, in order to support processing of multiple requests in
parallel, we now tag all Msg(Request|Response)(Batch)? messages with a
unique request id.

Implemented ListProcessor, MkDirProcessor and LinkDirProcessor to
support the 'ls' and 'mkdir' client commands as well as code within the
interactice client which issues the proper requests, processes the
responses and outputs information to the user.

Implemented handling of Msg(Request|Response)(Batch)? messages within
the server client loop.

Other changes contained in this diff:
- Finally move to using C++11 after fixing previously baffling compile
  errors encountered in core/server_group.hpp
- Added another async pipe action to perform one call of the client loop
  on a worker loop. This is used to wake up request processors once they
  become unblocked.
- More memory management fiddling in Msg(Response|Request)(Batch)?. One
  can now specify within the constructor whether or not the passed in
  request(s) or response(s) are to be destroyed upon the message
  destruction.
- Implemented LocalDirectoryHost subclassing DirectoryHost which
  opens DirectoryDBs at creation and provides APIs for retrieving the
  corresponding DirectoryDB object for a particular directory key.
- Fixed protocol operation constants to use the correct unsigned type
  uint32_t and to use the entire 32-bit space (was only using 28 due to
  typo).
- Dissambiguated the ErrnoResponse message type which previously took
  the type of the operation which was requested. This lead to cases
  where an operation like List which could either return an Error or a
  ListResponse would have no way of distinguishing within the protocol
  between the two options.
- Fold instance of . and .. directories within Path class.