Our servers are designed to launch multiple targets or analyses.
Targets run in threads (for now -- later, a special program will be
available to proxy-run them in another process, for server safety);
analyses run in processes.

Each launched target/analysis corresponds to a monitored object.  A
monitor is basically an event loop that monitors the launched
target/analysis, and proxies I/O into it, or signals it.

This introduces the concept of proxy requests, in which we process
requests in a request handler thread, demux them to figure out which
target/analysis they apply to, halt processing; then pass them to the
thread monitoring that target/analysis, reprocess, then respond.

This is complicated for a couple reasons:
  * some targets must only be accessed/controlled from the thread
    that is attached to them (attached in a debugging sense), so if
    our server is multithread/process and supports launching multiple
    targets (and it does), we have to *execute* requests in the right
    thread, which is not the incoming request thread.  This requires
    all sorts of gyrations, because not all our spawned entities are
    threads!  Targets can be spawned directly out of threads, but
    analyses run in separate processes; thus the requests must be
    forwarded (proxied) to them, and handled locally.
  * if we ever want SSL requests (to make it real, we would, because
    our server must run as root), we cannot just share the open socket
    to an analysis process and let it respond from that process,
    because we cannot forward the SSL state (even though we can forward
    the plaintext of the request for reprocessing).  This is not an
    issue for targets running in a thread, because we can share all
    the incoming request state, including SSL state, trivially.