Split broker into components

This is my idea for breaking the broker into a few parts, instead of being a monolithic executable. The rationale is:

• With additional rendezvous methods (legacy/trac#25594 (moved), legacy/trac#25874 (moved)), it will be nice to have a separate process per method, which can be restarted independently of the others and only has to manage its own listener.
• With encrypted registrations (legacy/trac#22945 (moved)), it will be nice if the process holding the private key is not the same process that exposes a lot of attack surface in the form of HTTP servers, DNS servers, etc.

I propose having the broker in three components:

1. The core broker database process, which matches client registrations with proxies. Only listens on localhost. Only handles plaintext.
2. A decryption and signing oracle process. This is the only component that has access to the private key. Listens only on localhost. Receives encrypted registrations from the rendezvous processes, decrypts them, and passes them on to the core broker process.
3. Registration method processes. These are the only components that listen externally. They take encrypted client registrations over HTTPS, DNS, or whatever, and pass them to the decryption oracle which passes them to the broker. Gets back signed proxy answers and passes them back to the client. There doesn't have to be strictly one process per registration method; for example the HTTPS POST and [ticket:25985 AMP Cache] are similar enough that they can be handled together. It might be better (simpler) to have components 1 and 2 in the same process--the broker logic is pretty simple so there's not much added risk in having it with private key.

We used a similar architecture in flash proxy; see facilitator-design.txt:

1. facilitator (later renamed fp-facilitator)
2. facilitator-reg-daemon (later renamed fp-reg-decryptd)
3. facilitator.cgi for HTTP and facilitator-email-poller for SMTP (later renamed fp-registrar.cgi and fp-registrar-email)