Fix cork_path_dirname near root of filesystem

There were a couple of bugs in the results of the `cork_path_dirname`
function when applied to the root directory, or to the root directory's
immediately children.
cork_path_cwd

This patch add a function for retrieving the current working directory
as a `cork_path` instance.  There is also a function for overwriting the
contents of an existing `cork_path` with the current working directory.
Merge branch 'feature/cwd' into develop

* feature/cwd:
  cork_path_cwd
Specify network connection to tile-monitor

This patch updates the tile-test script to use a network connection
when connecting to a Tilera processor using tile-monitor.  This appears
to address the problem of slow execution and shepherd process crashes
when connecting over the (default?) serial connection.
Bit sets

This patch adds a new type for storing arrays of bits.  Each bit in the
array can be on or off.  We always allocate space for all of the bits
in the array, regardless of whether they are on or off.
Copy-once slices

A copy-once slice can be used to wrap an existing buffer, when you can
guarantee that the buffer will outlive the slice.  This means that we
don't need to make an initial copy of the buffer; we can just use the
existing buffer directly.  The first time we copy the slice, though, we
duplicate the original wrapped buffer into a new managed buffer
instance.  (We have to do this because we can't make any guarantees
about how long the copied slice will live.)  We also go ahead and update
the initial slice (which originally wrapped the existing buffer
directly) to point into the new managed buffer.  This ensures that if we
copy the original slice twice, we won't create yet another duplicate of
the underlying buffer.
Lightly copied slices

You can now make a “light” copy of a slice.  This is similar to the
existing “full” copy operation, in that the new slice points into the
same buffer as the original.  However, by making a light copy, you
assert that you'll ensure that the newly copied slice will not outlive
the original slice.  Some slice implementations can use that guarantee
to make a copy with less overhead.  For instance, the new copy-once
slice already knows that the underlying buffer will outlive the original
slice, and will therefore also outlive any light copies.  That lets us
reuse the existing buffer for light copies.  (For full copies, we can't
assume any guarantees about how the life of the underlying buffer
relates to the lives of the new full copies, and so we still have to
make duplicate the actual slice content.)
Merge branch 'feature/copy-once-slice' into develop

* feature/copy-once-slice:
  Lightly copied slices
  Copy-once slices
Revamped resizable arrays

This patch makes some major changes to the resizable array
implementation.  The new implementation is API-compatible with previous
versions, but not ABI-compatible.  All code that uses resizable arrays
will need to be recompiled.

We no longer reserve space in the array itself for a small number of
elements; the element storage is now always allocated from the heap.
The `cork_array` type now contains a `priv` pointer, which lets us
maintain API compatibility with previous versions — in which you
allocate a `cork_array` instance yourself, while still being able to
maintain ABI compatibility moving forward.  (This ensures that the
public `cork_array` type is of fixed size, even if we add new features;
any extra fields needed for those new features will be placed into the
opaque struct that the `priv` field points to.)

More interestingly, you can now provide a handful of callback functions,
which let you automatically initialize and finalize array entries as
they're used and discarded.  You can provide separate initialization
callbacks for when an entry is used for the first time, or reused.
Similarly, you can provide separate finalization callbacks for when an
element is removed without freeing its underlying storage, and for when
the array element is freed.
Copying arrays

The new `cork_array_copy` function can be used to copy content from one
resizable array to another.  All callbacks are called appropriately.
You can provide a function to perform the actual copy; it will be called
once for each element.  (This lets you do a deep copy of the elements if
that's appropriate.)  If you don't provide a function, then we'll
bulk-copy the content using `memcpy`.
Merge branch 'feature/array' into develop

* feature/array:
  Copying arrays
  Revamped resizable arrays
Allow 0-length managed buffer slices

The general `cork_slice_*` functions allow you to create a 0-length
slice, but the constructor for creating a new slice from a managed
buffer does not.  We should consistently allow this.