Adding a single threaded variables.  Essentially, there are lots of pieces of Waldo data that are event-local, eg., sequence-local data.  Do not need to worry about locking on these pieces of data, nor checking any fancy lock holding during commit.  Still need to test and add compiler support for emitting single threaded variables.
Previous code checked with isinstance against ReferenceBase to determine if a variable was a Waldo object.  Because single threaded Waldo objects did not inherit from ReferenceBase, these were excluded.  Instead, created a new base class, WaldoObj, which both single threaded and multi threaded variables inherit from and use that for the isinstance check.
Changed isinstance tests in waldoExecutingEvent.py to take into account SingleThreaded variables as well as multi threaded.
Gabriel accidentally committed the test log earlier.  Removing it.
Forgot to remove a reference to now-deleted singleThreadReferenceBase (all that code got moved into waldoReferenceContainerBase).
Fixes a few bugs with previous commit (misspellings, misnamings, etc.)
that running through test cases exposed.
Require copy constructors for single threaded variables.
Removed last vestiges of logging code.  It was just getting in the way: nothing useful was being logged.
Merged performance branch with master.
Arrays can use Numbers as indices without throwing a TypeError Exception
Minor misspelling of append in type check.
After using a singly-threaded variable, you may need to promote it to
being used as a multithreaded variable.  For instance, if you create a
single threaded list and then append it to a multithreaded list of
lists, later accesses to the list should prevent read-write
conflicts.  This commit adds a promote_multithreaded method to
reference types to ensure that they become multithreaded after
commit.  Still needs lots of testing though.
Actually emitting single threaded variables instead of multithreaded variables.
Added test case to ensure that single threaded variables get promoted to multithreaded when they get incorporated into multithreaded variables.
Previous code did not promote the elements of each single thread
list/map elements.  This meant that could get to a point where two
multithreaded variables that had been pointing to the same single
threaded variable, after promotion, would point to distinct promoted
multithreaded varialbes (see addition to test cases committed for an
example when).  Fixed by deep promoting (promoting all the elements of
each single threaded list/map).
Performance branch adds single threaded variables to Waldo.
Essentially, many variables do not need to be accessed by multiple
threads simultaneously.  (For instance, the index variable of a for
loop.)  For these, it is needlessly expensive to make copies on
writes, take locks, etc.

Merge branch 'performance'

Conflicts:
	waldo/lib/waldoInternalList.py
Changed type of 'self' from wildcard to endpoint.
Added support for the built-in endpoint method 'id', which returns an endpoint's uuid as a string.
Previous Waldo design used a thread pool.  Each thread would read from
the threadsafe queue it was passed in and then it would service the
service action that it was passed in.

This design instead creates a new thread for each service action
provided, servicing the service action in the new thread.

Compared to previous approach, this approach has a lot of overhead
because thread creation in python is relatively expensive.  However,
for test cases that do not clean up after themselves, had to have very
large threadpools (~50 threads per endpoint).  On lower end laptops,
this meant that users would get a resource exhaustion error ("cannot
create more threads").  Until ensure that cleaning up enough that can
have smaller thread pools, going back to strategy of one thread per
service action.

(Note: from benchmark with dht code, code that used to take ~26s to
run with a thread pool now takes ~32s.)
Merge branch 'master' of github.com:bmistree/Waldo