(wip) Rewriting the Email Relay using the parent / child-worker model

EmailRelay now works by assembling several components:

 - `ImapMailbox`: can read messages from an IMAP inbox
 - `MailboxWatcher` takes a mailbox and an email handler; it checks the mailbox every so often and dispatches emails to the email handler.
 - `ForkingEmailHandler` takes another email handler; it forks a child process to invoke the other email handler
 - `EmailRelayer` takes a recipient resolver; it asks the recipient resolver to turn the email's recipient into an array of email addresses; it then copies the email to each of those addresses
 - `ApiRecipientResolver`: parses an identifier out of the mailing list address and asks Members or Unite who the recipients should be.

Notice that there some invisible roles:

 - `ImapMailbox` is a specific kind of Mailbox — any class than can enumerate emails can be a Mailbox.
 - `ForkingEmailHandler` and `EmailRelayer` are both kinds of Email Handlers — any class that implements `handle_email` is an Email Handler.
 - `ApiRecipientResolver` is a kind of Recipient Resolver that happens to invoke an external API.

Here's what I've got left to do:

 - [ ] Test that `MailboxWatcher` calls `check_for_email` every _N_ seconds
 - [ ] Extract a logger from `ForkingEmailHandler`
 - [ ] Figure out when emails should be deleted and where the concern for that should live; test
 - [ ] Handle errors (possibly just by logging and crashing)
 - [ ] Daemonize the relay
 - [ ] Finish the Integration test (involves designing configuration)
 - [ ] Figure out how to deploy (and restart) Email Relay
 - [ ] Figure out how to ping Email Relay to see that it's alive