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.
add rt-static-docs to extract documents
Ensure that links generated by the iCal feed are CSRF whitelisted

The link to the ticket used http://hostname/?q=1234 instead of the more
canonical http://hostname/Ticket/Display.html?id=1234 As requests caused
by clicking on the iCal link most probably come without proper referrer,
and /?q1234 isn't whitelisted, such requests would get the CSRF
interstitial.

Switch to the slightly longer, but properly whitelisted,
http://hostname/Ticket/Display.html?id=1234 URL.
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.
Generate TOC and HTML from pod in additional RT directories

Generate HTML from pod in docs, sbin, and bin in addition to
lib.

Subclass Pod::Simple::HTMLBatch to create docs from utilities
in bin and sbin and to create a custom TOC with documentation
sections.
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.
Modify generated docs for inclusion in bps site

Remove all header HTML, modify 'back to index' links,
add etc to get RT_Config.pm docs.
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