Normalized whitespace in be-handle-mail and send_pgp_mime.py.

Also removed "commit after every message" from be-handle-mail,
because
  a) not implemented yet
  b) don't want to commit spam, since we'd have to find a way to
  remove it later.

Suggested future workflow:
  * "bzr diff" to poll for activity, blank output = no activity.
  * on activity:
    1) look at changes
    2) remove whatever
    3) commit email-interface repo.
    4) merge changes into your private repo
  * on private repo changes:
    * if activity in email-interface repo:
      1) deal with email activity as above
    * push your private repo onto the email-interface repo
      (and update the email repos' working tree, if required)

Added "to_unicode" to send_pgp_mime.flatten()

be-handle-mail wants unicode output, since all it's internal
processing is done with unicode.  However, the flatten calls in
send_pgp_mime work with the encoded binary string output, and
execute(sendmail, stdin=flatten(msg, to_unicode=True)) fails
with
  Exception: u
  while executing /usr/sbin/sendmail -t
  sendmail: fatal: wking(1001): No recipient addresses found in message header

send_pgp_mime.py attempts to avoid UTF-8 for MIMEText messages.

This keeps the transfer-encoding out of base64 if possible.

Also added a "help" example to interafaces/email/interactive/examples.

Added send_pgp_mime.Mail.encodedMIMEText() for unicode handling.

Now be-handle-mail handles examples/unicode without crashing
  cat examples/unicode | ./be-handle-mail -o -l -
But the output email is encoded in base64:

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
From: BE Bugs <wking@thor.physics.drexel.edu>
To: John Doe <jdoe@example.com>
Date: Sat, 18 Jul 2009 12:22:05 +0000
Subject: [be-bug] Re: show
In-reply-to: <abcd@example.com>

UmVzdWx0cyBvZiBydW5uaW5nOiAoZXhpdCBjb2RlIDApCiAgc2hvdyAKCnN0ZG91dDoKCjw/eG1s
IHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04IiA/Pgo8YnVnPgogIDx1dWlkPmY3Y2NkOTE2
LWI1YzctNDg5MC1hMmUzLThjOGFjZTE3YWUzYTwvdXVpZD4KICA8c2hvcnQtbmFtZT5mN2M8L3No
b3J0LW5hbWU+CiAgPHNldmVyaXR5Pm1pbm9yPC9zZXZlcml0eT4KICA8c3RhdHVzPmZpeGVkPC9z
...

This is perhaps the best we can get out of python < 3.1/2.7, see
  http://bugs.python.org/issue1368247

Add unicode-header handling to send_pgp_mime.py

Also:

Switched
 email.message_from_string()
to
 email.parser.Parser().parsestr()
for parsing the header, for access to the headersonly option.

Adjusted module import order to alphebetize non-mime email modules.

Added return_realname to source_email(), which makes it more useful to
be-handle-mail (currently uncommitted).

Added a doctest for the plain() output and removed redundant
Content-Type line from the doctests (which we'd removed from the
output with the last commit).

Note that many doctests _will_fail_ unless me@big.edu and you@big.edu
are in your gpg keyring.  At some point I should make those addresses
options to --test...

Minor tweaks in send_pgp_mime.py

 * No reason to set maxheaderlen to something other than the default.
 * MIMEText sets content-type and charset automatically.

Added --mode=plain option to send_pgp_mime.

Also a few more tweaks to get things working.  I think be-handle-mail
is parsing the incoming messages correctly now, but I'm not getting
replies back for some reason.  Some of the adjustments:

  * Moved send_pgp_mime -> send_pgp_mime.py, otherwise Python doesn't
    recognize it as an importable module.
  * I use postfix now instead of msmtp, so send_pgp_mime.sendmail now
    points to postfix's sendmail-compatable frontend.
  * Added "--mode=plain" option to send_pgp_mime.py, so I can test
    my procmail rules and send_pgp_mime itself without worrying about
    be-handle-mail.
  * Fixed some typos in be-handle-mail.

Added some comments to send_pgp_mime

Added my send_pgp_mime module to the project.

This is a bit of a shameless plug, since there's not much motivation
for encrypting bug emails.  However, I've already written it, and it
does send emails, so I'm using it ;).  Perhaps some company will want
to keep the bug submitter's contact information securely in a BE
database.  Anyhow, there's very little reason to _not_ use PGP, and
the module certainly doesn't force you to encrypt anything. ;)