Message parsing in public API

I've tweaked the existing internal helper functions for encoding and
decoding messages and put them into the public API.  They now operate on
the new `crs_message` type, which encapsulates the content of a message
sent across the overlay network.  Each message instance is either in
write-only mode or read-only mode.  Write-only mode allows you to append
data to the message, building up the message content in pieces.  You
then give the message to the overlay network, allowing it to route it to
its destination.  On the receiving end, we create a read-only
`crs_message` instance, which is decoded and passed to the application
that should process it.  During read-only mode, we maintain a cursor
into the message content, which is advanced forward as parts of the
message are decoded.  This lets us divide up the decoding responsibility
— the node itself is responsible for decoding the application ID, for
instance, while the application code is responsible for decoding
everything after that.

Right now when writing, all of the message content is concatenated into
a single buffer.  The API should allow us to replace that with some kind
of rope structure, if we want to try to support scatter/gather in the
I/O layer.
Construct node references from addresses

Before, the constructor function for a node reference took in both a
Pastry identifier and a network address that we should use to contact
the underlying node.  However, we won't always know in advance what
Pastry identifier to use.  In particular, for the bootstrap node, we
only have a network address.  So now it's the responsibility of the node
reference constructor to contact the node to see what it's Pastry
identifier is.
Applications have names

Each application that's registered with a Croissant node now has a name
in addition to a 32-bit ID.  We use this in some new logging messages to
make it clearer how messages are routed between nodes and to an
application on the destination node.
Ignore duplicate entries in leaf sets

If we try to add a node reference to a leaf set, but the leaf set
already contains that reference, we shouldn't add a duplicate copy.
Applications can intercept messages

Each application can now provide an `intercept` callback, which is can
use to spy on or override the routing behavior of the overlay network.
The `intercept` callback is given a reference to the `next_hop` node for
the basic routing protocol.  The default implementation simply forwards
the message on to the `next_hop` node.  Some applications will want to
override this behavior, either to perform extra logic when a node sees a
message in transit, or to re-route the message in some
application-specific way.
Routing tables must contain local references

A “local” reference isn't a reference that refers to the local node,
it's one that's owned by the local node.  This is only really an issue
in our test cases — since everything is in the same process space, it's
easy to mix up the various `crs_node_ref` instances that refer to the
same node.  We now have some assert statements that should make sure
we don't let node references cross over into nodes that they don't
belong to.
Initial node joining protocol

This patch adds an initial implementation of the Pastry node joining
protocol.  The first node in the network just starts, with an empty leaf
set and routing table.  All later nodes must know the address of some
existing node, which is contacts with a special JOIN message.  At that
point, the existing nodes route a series of messages back and forth
between the new node to exchange leaf set and routing table information.
The details can be found in [1].

This patch does not yet implement the enhanced node discovery algorithm
from §4.3.  Right now we just start the node joining protocol with the
existing node reference.  Eventually we'll want to implement §4.3, where
we first find the address of a nearby existing node, and then execute
the existing node joining protocol with it.

[1] M Castro, P Druschel, YC Hu and A Rowstron.  “Exploiting network
    proximity in peer-to-peer overlay networks”.  Technical report
    MSR-TR-2002-82, 2002.
    http://www.freepastry.org/PAST/location.pdf
Merge branch 'feature/join' into develop

* feature/join:
  Initial node joining protocol
  Routing tables must contain local references
  Applications can intercept messages
  Ignore duplicate entries in leaf sets
  Applications have names
  Construct node references from addresses
  Message parsing in public API