Tor multithreaded crypto

[George Kadianakis]

Following the "Release early, release often" principle, I'm posting
today's revision of the multithreaded crypto changes.

This time I've spent some time fixing the code and I've even
semi-tested the queues.  
By semi-tested I mean that I made a small program with the queue code
but with the normal pthread_* functions and not the Tor wrappers and
with char* values getting passed around instead of circuits and
cell_directions etc.
I guess that's not considered commercial-quality QA, but at least it's
something!

Code is obviously still immature and nothing much changed but I think
that this time it may handle some lightweight code review.

Now, two questions:

a) Like I said in #tor-dev, the packed relay cell throughout idea was
nice, but I've ended up adjusting _many_ functions to support this
change [1]. We need to find out if:
* I'm doing it right and it indeed needs so many changes.
   * If I'm right, if it's worth doing all those changes.
   
b) Nick, can you expand a bit on how and where should the interaction
between Libevent and the main thread should happen? Basically, when
the 'unhandled' cell queue gets filled how should Libevent notify the
main thread? And where in the main thread should we be waiting for
Libevent wakeups?

Now:
In http://people.cs.unipi.gr/asn/tor you will find:
- multicrypto.c
  This is the file where the work queues and the relay_crypto_worker
  code is held. This will - most probably - get split later, but I
  guess it's readable enough for now.
- experimentality.c
  This is the file where relay_crypt() and
  handle_encrypted_relay_cell() are held. These will most probably go
  to relay.c or to somewhere meaningful, but they are still in an
  awful state because of the transition to packed_cell_t so I have
  temporarily moved them to this file.
- packedchanges.diff
  All the ugly adjustments I've done to support packed_cell_t in
  various relay-related (and not) functions.
  Careful it's a bit bloated file.
  
Comments are more than welcome, of course, although do remember that
it's far from done and it's still more of a blueprint than the actual
implementation. 

Thank you :)