Remove all whitespace separating adjacent encoded-word chunks

RFC 2047 says:

   When displaying a particular header field that contains multiple
   'encoded-word's, any 'linear-white-space' that separates a pair of
   adjacent 'encoded-word's is ignored.

Implement this by explicitly removing all such whitespace.
Join all adjacent QP encoded-word chunks, in case octets were split

Though not allowed by RFC 2047, some mail clients split multiple octets
of a multibyte encoding across different encoded-word chunks.
Reassemble adjacent encoded-word chunks into one, as long as they match
in encoding, language, and transfer encoding.  Only quoted-printable
chunks are joined, as joining base64 hunks is much more complex.
use lookahead in s/// instead of while loop
Make the date entry widgets on bulk update page be datetime widgets

All of the fields in question are actually datetimes, not simply dates.
The ShowTime => 0 flag dates from 86ef6b2, when the bulk update
functionality was first added, and is erroneous.
Switch tests to check names of queues in addition to ids of queues

Otherwise we weren't noticing that a queue name change listed the
correct queue (id wise) in the Select Queue dropdown, but missed the
name change.
Test that changing a Queue's name is reflected in the dropdowns

We're doing this in _Set because the Description is also cached (although
currently unused) and it probably makes sense to just bust the cache a
little more often rather than end up with another bug like this.
Allow the passing of actions through to Abort

When a change causes a ticket to no longer be viewable to the user, the
results of the change are now at least displayed to the user.
Fix a typo, preventing emails from setting internal encryption header

X-RT-Incoming-Encryption, along with a number of other headers, is
removed from all parts of incoming emails because they are used to
annotate GPG-related properties of the message.  Fix a typo, which
allowed the properly-spelled header to pass through under specific
circumstances.
Remove internal signing and encryption hints from incoming mail

RT uses the existance of the X-RT-Sign and X-RT-Encrypt headers to
decide if the outgoing mails it sends as a result of the transaction
should be signed and/or encrypted.  It standardly inserts these headers
based on checkboxes visable in the web UI; however, it fails to remove
them from incoming mails, allowing external users to create nearly
arbitrary messages signed by the queue's key.
Make tests pass on inline server, which caches callbacks across restarts
Restrict users to only signing with queue or their own personal keys

While the UI only presents two options for signing, the underlying form
accepted any key ID or email address, and dutifully signed the mail with
the appropriate secret key.  Restrict the accepted values of SignUsing
to the two values that we displayed.
Don't propose any secret keys to users with no email address

GetKeysForSigning, when called with 'force', returns all keys if no
email address is provided.  This caused users with no email address to
have all secret keys offered to them.  Remove the 'force' to ensure that
empty email address are shown an empty list.
Explicitly restrict private keys to ones offered
Avoid spurious update and warning messages on key update

This avoids an ominous-looking warning about failure to remove the key,
when no key was previously set but no key was newly selected.
Require AdminUser to set PGP private key IDs, not merely ModifySelf

Be explicit that modification of the PrivateKey pseudo-column requires
admin rights -- namely, AdminUser, not just ModifySelf.  While the page
that controlls that property is in /Admin/Users/GnuPG.html, accessing
that page requires only the ShowConfigTab right, and modifying the
property on yourself required only ModifySelf.  Combined with the
ability (also granted by ModifySelf) for users to change their own email
addresses, this opened the possibility for users to claim arbitrary
private keys as their own, for use in signing.
Ensure that no --arguments can be snuck to GPG commands as arguments

GnuPG::Interface 0.46 adds code to prefix command_args with a "--" if it
doesn't have one already.  Rather than bump the dependency, explicitly
add the "--" in the two places that we pass in command_args.
Refactor shared code controlling if a message will be encrypted or signed
Refactor RT::Action::SendEmail->Commit to consolidate RecordOutgoingEmail path

Instead of interweaving the logic around the case where
RecordOutgoingEmail is disabled, resolve that simple case first.
When creating tickets via the UI, always set signing/encryption headers
Differentiate "always sign" from "default to signing when composing"

Signing incorporates two related but distinct concepts: first,
verification that the message was transmitted without corruption
(integrity), and second, proof that the message was indeed sent by the
sender (authentication).

When the "Sign by default" queue option is disabled, the only messages
which are signed are those triggered by an action where the sender has
explicitly checked the "Sign" option.  Consequently, messages which are
not generated via the web UI, such as auto-replies, or requestors'
messages which are forwarded to owners, are not signed.  In this
configuration, the signing conveys authenticity, but does not provide
integrity for all messages..

When the "Sign by default" queue option is enabled, all messages default
to being signed, even ones generated automatically.  Thus, emails from
the requestor (which may have arbitrary content!) will be signed by the
queue's key when redistributed to owners and AdminCcs.  In this
configuration, the signing ensures integrity, but (because signing
happens automatically) means that no authenticity should be attached to
messages thus signed.

Because the simple configuration option fundamentally changed the
meaning of the signature, exchanging integrity for authenticity, with no
warning, alter it to instead provide an additional option ("Sign
auto-generated messages") which takes the burden of this change in
meaning.  Degrade the "Sign by default" option to describing the default
state of the checkbox on the ticket create or reply page.