attempted to make matched_pair generation deterministic
made it deterministic; made determinism togglable
added thread interrupt
~22min nondeterministic; optional determinism
resolved spurious merge
added threshold to levenshtein distance calculation

running time for default case now ~8min
got lein to run the junit tests
got lein (kinda) working with command line arguments... still pretty brittle
adding take() function to _thred.pool interface
added take() and get() functions to pool; calling code much cleaner
added take() and get() functions to pool; calling code much cleaner
added private static _thred._is_done function
Merge branch 'dev' of github.com:nroza/grey-duck into dev
adding preemptive levenshtein limiting; insofar as execution time is concerned,
this might one of the better ideas I've had in a while
fixed (maybe) the livelock in pool_ordered.poll that was seen for deterministic
pair generation where the matched_pair handler function initiated pool shutdown

This handler-initiated shutdown effectively (but not actually) cancelled
whatever futures where in the pool_ordered.fts_ collection. These orphaned
futures could never be completed since the executor service backing the
completion service had been gently shut down.

This solution assumes that once shutdown completes, the pool_ordered.que_ (the
completion queue) and pool_ordered.fts_ are guaranteed to have the same
contents, if not necessarily in the same order.