Initial drop of multitools lib from the CD archiver project.
Added listeners
Created distutils config so this becomes a site-packages lib, usable by
other projects.
Improved listener functionality so listeners receive messages to
derivatives of the specified message types, not just the exact type.
Switched the concept of loggers for that of resident processes;
Resident processes are those that are purely reactive, and should
terminate once all other processes terminate; Loggers can be implemented
using broad-based listeners that are resident
Eliminated LoggerProcessesMessages which send a list of names and
corresponding ids to a logger.  Might need to replace this in the future,
but it might be better to have a system which allows the logger to ask for
a name for an id.
Made listeners able to listen to messages not sent to target_id==1, so that
loggers as a concept still work (duh!)
Made sending messages use sets when resolving ids into input queues.
Used set comprehension instead of iterations, for neatness and speed
Fixed DebugLogger to use self.prnt not print, so it actually
prints debug statements now!
Introduced constants for broadcast and listener-only message
targets, rather than using 0 and 1 (use ProcessList.BROADCAST
and .LISTENERS as your target_ids now)
Using collections.deque for the Process.queries list for performance reasons.
Using a duplex Pipe rather than two Queues for input and output, for perf.
Added test for non-blocking pre-querying of ids.
Fixing TODOs
Improving docs
Speeding up tests (reduce sync wait - still seems to work!)
Note: Can't replace messaged['val'] from testPrnt() with
multiprocessing.Value() since the problem is not sharing state
with processes, but sharing state across a function boundary.
Split IPC/Supervisor functionality out into new Supervisor class for better encapsulation and quicker testing once I split out these classes into separate files
Fixed it so that handleMessage can return False so stop everything.  Currently untested; added TODO note in testing, as it's currently untested.
Made wrap_op private because, well, because I can.
Added testing for the newly slim ProcessList class.
Resubmitting yesterday's changes without github's mistake.
Broke out ipc code into submodule.
Broke out supervisor and client process code, as well as ipc messages and
logger code.
Hacked TestProcess (in client.py) to not depend on supervisor code from
host.py.
Adding license, as provided by GitHub.
Adding README and guide documentation.
Improving API due to thoughts from writing the guide docs
Note: Docs have not been reviewed yet, and code samples have not been tested
Fix obvious syntax error in guide.rst
Improving guide documentation.
Fixing code examples to be runnable.
Adding prntMessage for client.Process.prnt() to use, so users can
  use StringMessage without unintended consequences.
Reintroduced client.Process.send_object() for users still using
objHandlers.
Fixed Issue#3 ( ipc.client.Process objects can't be started by
  ProcessList.start() or self.start() )
Renamed client.Process.m_id as p_id (process id)
Added host.Supervisor.poll_message()
Made get_ids return a set, not a list
Made sure supervisor responds to all messages, even after processes
  terminate.
TOFIX: Poll time shouldn't depend on the number of processes in
  Supervisor.get() any more
TOFIX: Supervisor.supervise() calls self.send() to RESIDENT processes.
  That should be send_object now.
Fixing last commit todos:
  RESIDENT process term message sending didn't need fixing - it's send()
    in the supervisor to send a pre-instanced message object (not
    send_object() like in the client.Process)
  Fixed poll timeout to be consistent regardless of number of processes,
    but test_send_object is now a lot more flakey, despite adding a tick
    argument to get_message() to try to run things as they used to.
TODO: Find out why test_send_object now fails so often
Fixing flakey behaviour in test_send_process by making the tick actually like
 it used to be (tick is currently 0.2s, not 0.1s).
Still need to investigate exactly what was going on.  Does recv() behave in
  a last message first manner if it's got two messages queued up?
Fixed c&p error in section: print handler

Deleted spurious text in user guide.
Adding missing blank test cases (see Issue#1: Increase test coverage in
  ipc.client)
Sorted test cases into same order as class code.
Merge branch 'master' of https://github.com/williain/multitools
Fixing doc review comments
Fixing Issue #1:Increase test coverage in ipc.Client