Consolidate all BriefDescription generation for transactions

Most handlers were in the %_BriefDescriptions hash, but some remained
outside in the method for no apparent reason.  Consistent handling is
easier with them all in one place.

The few regex comparisons are now string equality, but the regexes
aren't necessary for any core RT transaction types.  Any extension which
created transaction types matching

    /(Status|SystemError|Forward (Ticket|Transaction))/

but not matching those unrolled fixed strings will now need to add
handlers to %RT::Transaction::_BriefDescriptions.
Provide transaction brief descriptions as HTML

None of the descriptions are actually HTML yet, but the method is
available and waiting for descriptions to be HTML-ified.

Plain text brief descriptions are now scrubbed versions of the HTML for
consistency and single point of maintenance.

Instead of calling loc() themselves, the description handlers now return
a list which is passed to loc() after being properly escaped.  The
handling is similar to column map return values: scalar refs are passed
through unescaped, array refs are recursively processed and joined into
a single value, and everything else is HTML escaped.  This makes it easy
to start providing HTML descriptions without the hassle of escaping and
concatenation everywhere.

One negative side-effect of this is that all the localizable strings
will lose their example parameters when extracted into the message
catalog.  We can remedy this in the future by providing a comment mark
like #loc that also captures following parameters.
Use the HTML transaction descriptions in history
Link to the objects or URIs referenced by AddLink and DeleteLink transactions

The Links are now links!  And clickable!
Link to the transaction that was forwarded

Now people don't need to poke through the HTML or hover over dozens of
anchors to figure out which transaction was forwarded.  Unlike outgoing
email record transactions, which occur immediately after the relevant
comment or correspond, forwards often occur much later in history.
Link to added/started/completed reminders from their history entries

We don't expose reminders through the normal ticket display framework,
so link only to the per-ticket "all reminders" page, scrolled to the
specific reminder in question via an anchor.
Use the per-reminder anchors for links in "My Reminders"
Remove extraneous license lines from the ShowUser components
Attempt to load a user from the supplied address for all user formats

Refactors the logic of ShowUserConcise into ShowUser to apply to all
cases.  ShowUserVerbose is able to display more information if only an
address is passed and but it corresponds to an existing RT::User.  An
RT::User object is always better than just an email address.
Move ShowUser* components into RT::User

These formatters generally deal in just text, not HTML, and they can't
be used by other library code when written in Mason.
Add a callback to ShowUser to allow for HTML injection into the format
Replace some calls to /Elements/ShowUser with Format in RT::User

Calls which aren't in full HTML contexts should call the method to avoid
any HTML.  This includes most loc strings, <option> contents, RSS
elements, and autocomplete results.  Almost any call to ShowUser which
sets NoEscape to a true value should probably be using $User->Format
instead.
Show all users in history using the current user's preferred format
Wrap mentioned users in history with an identifying <span>

This helps future extensions customize the history display of users.
Normalize forward recipients before sending and adjust tests to match reality

None of the usual parsing and normalization of email recipients was done
when forwarding tickets or transactions.  Use RT::EmailParser's
ParseEmailAddress method to convert to Email::Address objects
(effectively a split), then reformat and join back together.  This
ensures domain-less usernames are supported in forwards just like
elsewhere.  Importantly, this change also ensures the transaction
recording the forward action has a Data column which is guaranteed
parseable.

The forwarding tests previously tested a domain-less user in the same
field as a full email address, which is not supported by RT's email
parsing and would likely never work as expected with a real MTA.  Switch
to testing domain-less users are parsed correctly when in their own
recipient field.

These bugs were uncovered by RT::Transaction's new parsing of $txn->Data
for generating history descriptions.
Don't distinguish between visited and unvisited links in transaction descriptions
Merge branch '4.2/html-transaction-descriptions'

Conflicts:
	docs/UPGRADING-4.2