Routing tables

The `crs_routing_table` type will be used, surprisingly enough, to store
the routing table for a Pastry node.  We have some test cases that make
sure that we get the right routing table when we add a bunch of entries
to it, but nothing more complex than that just yet.
Add proximity field to node references

Node references now include a proximity metric.  (Larger values indicate
that the referred-to node is further away from the local process.) Right
now we only have local nodes, so every node reference's initial
proximity value is 0.  In our test cases, we artificially make some
nodes seem further away so that we can verify that the routing table
manages conflicts correctly.  (I.e., when two node references would both
be stored in the same entry in the routing table, the “closer” node
reference should win.)
Include destination ID when sending messages

The `send` function needs to include the Pastry ID of the message's
destination, since this will quite often not be the same as the ID of
the node that we're sending the message, too.  In addition, the
`crs_node_ref_send` function isn't going to be the primary public
interface for sending a message; instead, it will be a mostly internal
helper function that our routing implementation will use.  Users of the
library will use the (not yet written) `crs_node_send` function, which
will use the Pastry routing algorithm to find the right physical node to
send the message to.
Context objects

We now store the list of local node objects in a “context”.  In addition
to managing the lookup of local nodes, the context is also responsible
for freeing those node objects.  In addition, each node reference is now
“owned” by the node that created it.  (We don't have the context object
manage the references, because we want local nodes to be consistent with
remote nodes, in that each node has its own distinct set of references.
In particular, this should allow us to test what happens when two nodes
with the same ID try to join the pastry network.)
`croissant test` program

The new `croissant test` program reads in a list of commands from stdin.
These commands can be used to construct and test a Pastry network.  This
might seem a bit overkill for now, but eventually we'll probably need
test cases that need precise control over creating Pastry nodes, joining
them together, and sending messages between them.  So now's a good time
to start working on the framework.
`add routing table entry` test command

The new `add routing table entry` can be used in our test program to
explicitly add an entry to a node's routing table.  The target node must
already have been added to the network.
Comparing pastry IDs

The `crs_id_is_cw` and `crs_id_is_ccw` functions can be used to compare
two Pastry identifiers.  Because the IDs exist on a modulo ring, the
names of the functions refer to “clockwise” and “counter-clockwise” on
that ring.  The clockwise relation corresponds to the non-modulo >=
operation: “0003 is clockwise of 0002” is the equivalent of “0003 >=
0002”.