Remove the need for explicit row locks when allocating UIDs.

The existing code with explicit row locks exhibited very poor
performance, and also prevented multiple TSDs from allocating
UIDs concurrently.

The new approach consists in:
  1. Performing an atomic increment to grab a new UID.
  2. CAS'ing (CompareAndSet) the reverse mapping (uid => name)
  3. CAS'ing the forward mapping (name => uid)

If we die after step 1, we waste an UID.  If we die after step 2,
we just end up with an orphaned reverse mapping (harmless).  When
two TSDs race to assign a UID to the same name, one of them will
fail to CAS the forward mapping at step 3, and will retry to find
the UID assigned by the winning TSD.  When that occurs, the only
net consequence is that a UID will have been wasted by the losing
TSD, whereas the previous implementation wouldn't waste one when
this happened.  The 'uid fsck' command can easily detect orphaned
or wasted UIDs, and we could conceivably put them on some kind of
a free list in the future to re-allocate them.

If two TSDs are running side-by-side, and one uses the old method
while the other uses the new lock-less method, things still work
as expected.  There are two possible scenarios:
  - Old TSD goes first, locks the MAXID row, and does its thing.
    The new TSD will have to wait until the row lock is released
    for its atomic increment to go through.
  - The new TSD goes first, atomically increments the MAXID row,
    and does its thing.  The second TSD locks the MAXID row and
    proceeds to allocate its own ID concurrently.

Conflicts:

	NEWS
	src/uid/UniqueId.java
	test/uid/TestUniqueId.java