Added "Confirm" and "Subscribe" pseudoheaders to be-handle-mail.

Added "Confirm" and "Subscribe" pseudoheaders to be-handle-mail.

Allowed values for both are "yes" or "no", case insensitive.

Setting Confirm:no disables the confirmation email letting you know
your new bug was successfully submitted.

Setting Subscribe:yes automatically subscribes you to the new bug
you're submitting immediately, without reqiring an extra control
email.

In the case where both Confirm:yes and Subscribe:yes, the submitter
will only recieve the subscription email (which shows the "be show"
view of the new bug) and not the submission email (which shows the
output of all the executed submission commands).

Both of these pseudoheaders were in response to a
  Would you like a direct response concerning your comments?
checkbox on the web frontend that generates emails for a BE repo.
When the checkbox is set, we set Confirm:yes Subscribe:yes, and the
submitter gets a nice pretty confirmation email and will be
automatically notified of any future action on their bug.  When the
checkbox is not set, they get no response or submission emails.

Also fixed up some bugs in in the subscriber_emails() parsing.  We now
use ordered_subscriptions to ensure that we parse the "DIR"
subscription first, since we don't want to include the same
information twice, and the user might be subscribed to DIR:all and a
particular bug (which would be wierd, but is easily avoidable).  This
also ensures that the more central DIR level changes appear first in
the email.

We also check that there is an entry for a particular bug in bug_index
before attempting to grab it, which could raise KeyErrors otherwise.

Finally, we check to make sure we don't double-include bugs for which
the user is subscribed to both that bug's new and DIR:new.

A final minor correction is the capitalization of the first word of
our log entries.  The logs are pretty cluttered, and the
capitalization helps the lines I care about stand out.  A better
solution would be to come up with a cleaner idea of what to write to
the logs...