using a separate lock for touched objects so that if we are holding
the commit lock on this event, we can still access the touched_objs
map (for promoting priority).  note that the only time we will write
to touched_objs is when we have already used the event's _lock method.
Therefore, if we are already inside of a _lock and just reading, we do
not need to acquire _touched_objs_mutex.
Started filling in additional structure for promoting boosted events.
This included two big changes:

  1) Creating separate locks for data structures in waldoLockedEvent.
     Doing so to avoid potential cases of deadlock's occurring through
     promotion.

  2) Added code flow for promotion.  Calls several (currently) empty
     methods.
Each event has a priority associated with it.  This priority can
change when an event gets promoted to be boosted.  To avoid the
read/write conflicts this might cause, instead of operating on an
event's real-time priority, when trying to acquire read and write
locks on events, we initially request their priorities and use them
for the main body of that operation.  This priority gets cached in
WaitingElements and can get updated, asynchronously, when an event
requests promotion.

I still need to changed write_lock_holder and read_lock_holders to use
cached priorities.
Using cached priorities for read lock holders.
Now using cached priorities for write lock holder.  That way,
priorities cannot change out from under us when trying to acquire read
and write locks.
Promotion now updates event priorities on a single node's locked objects.  Now need must add forwarding promotion messages to partners and endpoints called.