Use mangler and tiddlywebconfig

This just makes it easier to use local code and config in
these tests.
Add paraclient and parastore

These are the main beasts and are very crufty: loads of just
playing going on here to learn and explore.

parastore is a SocketServer subclass that listens on a unix socket
and will fork to handle a request embodied in that socket. the
request identifies a tiddler in a bag. The forked child loads tiddler
data from the store and then writes that info back down the socket.

paraclient, given a list of a tiddlers, makes connections over the
parastore socket, writing tiddler identifiers. It then waits in a
select loop for data coming back from the server and its children.

The select blocks until at least one of the file-like things (including
sockets) it is watching has data. The kernel handles this side of
things. For each of those things, the data is read and a proto tiddler
is yielded.

With the data set currently in use, this works: tiddler data is
yielded, sometimes out of order.

If the number of tiddlers is raised, or the listen queue lessened,
things start to go wrong, probably as a result of ignorance (or
fatigue) on my part. Something is definitely not complete in
the setup as children are not being effectively reaped after
they exit and thus are staying behind as zombies.

It appears that because of the zombies we can easily run out of
available children.

If the code can be made to work correctly, meaning:

* reap children
* properly fork
* properly open and close sockets
* properly connect when writing to the server
* have the right number of open sockets and only write on them
  when we have data

it still won't be correct as there are additional things that would need
to be done before it could be evaluated as a proper tiddler provider:

* some kind of serialization format would need to be used to get
  tiddler objects from the socket server to the client cPickle is a
  likely choice, but will likely need to trim the objects before
  pickling (any \.store

Then yet more concerns come along to evaluate the concept:

* If a tiddler is already in memcached how redundant is this going to
  be?
* What level of parallelism is appropriate? It's not as simple as
  number of cpus as the whole point here is working around i/o wait.
* What is the relative cost of pickling?