Huge bug, when acquiring a write lock, should allow acquiring a write
lock if no one else is holding one, not "should allow acquiring a
write lock if someone is holding one."
Changed comment in try_next: it's important that we perform try_next
in order of *priorities*, not uuids.  If we perform checks by
priorities, then we can short-circuit evaluation of waiting list as
soon as hit read we can't apply or any write.
All priority comparisons should be handled in EventPriority.java, not hand-coded separately each time.
Note: should use .equals comparison instead of == for objects in java.
By sorting by uuid, can guarantee no deadlock between two objects
backing out of events simultaneously.  If sort by cached_priority, can
get deadlock if one events' priority has not been pushed to the
others'.
All priority comparisons should be handled in EventPriority.java, not
hand-coded separately each time.
Should always output fixed-width integers from clock.  That way, can
have meaningful comparisons in priorities.  Eg.,

Timestamp 2 should create higher priority than timestamp 18.  However,
when turn into strings, comparing:

12...
vs
118...

and 118 appeared to have higher priority.
Problem trying to solve:

Endpoint A would dump 100 events into system.  Then Endpoint B would
dump 100 events into system.  Previous commit ensured that they would
alternate at beginning:

a event
b event
a event
b event
...

But, at end, could get:

a event
a event
a event
a event
b event
b event
b event
b event

I realized that this was because both A and B had their Lamport clocks
at the same timestamp, eg., 78.  What would end up happening then is
that the boosted events on A and B would have the same prefix and
would only vary on their randomly-generated bits.  If B generated an
unfortunately low priority boosted priority then, it would wait as A
generated a series of higher-valued priorities.  Whenever A completed
an event, it would just get its clock's timestamp, which would still
be 78 (because no new events were being put into the system).  Then
B's unfortunately low priority would still be less than A's new
boosted and A would take preference.  The solution was to increment
each endpoint's Lamport clock when each Boosted event completes.
Cleaned up test to ensure that boosted scheduling algorithm runs
correctly.  Added more comments and actually checked ordering of
results instead of just printing them to screen and making runner
manually verify.