[wip] Spawning pool

Time to shave off that final 2-second delay. This PR implements #32 by pre-launching a configured *(by which I mean hardcoded to "3")* set of containers and handing them out to incoming requests. When a container is culled for inactivity, it's scrapped and a new one is launched and added to the pool in its place.

If you hit `orchestrate.py` with a path already set (using a stale link, for example, or an appear.in-style link like #67 implements), you have a personal container created and linked as it happens now.

/cc @rgbkrk so he can see just how terrible this is right now, and suggest embetterment techniques :wink:
> Idea: Check if a running notebook container is not on the proxy.
> 
> Problem with that idea is when the proxy restarts we don't know if the leftover containers were used or not.

Really, we're now storing state in *three* places: Docker; the proxy; and the orchestration script. If any of the three fall out of sync, we're going to have problems.

I'm not sure what the best way forward would be, here. If I picked one as The Source of Truth I'd go with Docker. Maybe I should look at `docker-py`'s documentation a little more closely to see how difficult it would be to reconstruct everything from your running containers on launch.