This is not only for code consistency, but also for consistency of
output.  Encode::encode_utf8(...) is equivalent to
Encode::encode("utf8",...) which is the non-"strict" form of UTF-8.
Strict UTF-8 encoding differs in that (from `perldoc Encode`):

    ...its range is much narrower (0 ..  0x10_FFFF to cover only 21 bits
    instead of 32 or 64 bits) and some sequences are not allowed, like
    those used in surrogate pairs, the 31 non-character code points
    0xFDD0 .. 0xFDEF, the last two code points in any plane (0xXX_FFFE
    and 0xXX_FFFF), all non-shortest encodings, etc.

RT deals with interchange with databases, email, and other systems.  In
dealing with encodings, it should ensure that it does not produce byte
sequences that are invalid according to official Unicode standards.

Placing wide characters into MIME::Entity objects can lead to
double-encoding.  Always treat them as byte stores, encoding as UTF-8
and noting their character set.

In the case of Approvals/index.html, there was no need for an explicit
MIME::Entity object; ->Correspond creates one as needed from a "Content"
argument.

$sub_fow may be undef, but is displayed at the debug level.  In the one
codepath in which it is used, it is defaulted to 1.  Push this default
to above where $sub_fow is used in the debug statement, to avoid
warnings.

there is line length limit for messages in rfc 2822(section 2.1.1).
though some email systems can auto-wrap long lines perfectly, some did it poorly.
dashboard html can have very long lines(1000+ chars, e.g. when there are links
to customized searches with long queries), setting to base64 here is to make sure
it won't be cut off by buggy email systems.

there is line length limit for messages in rfc 2822(section 2.1.1).
though some email systems can auto-wrap long lines perfectly, some did it poorly.
dashboard html can have very long lines(1000+ chars, e.g. when there are links
to customized searches with long queries), setting to base64 here is to make sure
it won't be cut off by buggy email systems.

The move of JS to static didn't affect the dashboard mailer since all JS
is stripped.  With CSS now static, however, requesting it through Mason
doesn't work since our static handler is at the PSGI level.

Instead of our ad-hoc solution.  Less maintenance burden.

Although remote resources like images and CSS aren't present in RT by
default, local customizations may add them.  Previously the remote path
was blindly requested from Mason, with no chance of success.  Instead
just leave remote resources alone.

Dashboard names, included in the Subject, may contain Unicode characters
which need MIME-word encoding first.  MIME::Entity doesn't handle this
for us.  This was reported by Christian Loos <github@netsandbox.de>.

From and To are passed through encode_utf8() to avoid double encoding
issues in MIME::Entity, which only handles octets well.  See the full
rationale in 57ea0c02.

Unlike Subject, From and To don't get the EncodeToMIME treatment because
MIME-word encoding From and To as an opaque blob is really, really
wrong.  You need to encode on a per-recipient level using Email::Address
to parse, otherwise you can lose special chars such as commas into the
MIME-word.  While From is likely just an email address, To is non-admin
user-input and may contain commas or an email phrase part or other
formatting.  See also the bug [1] in ContentAsMIME where we _do_ use
EncodeToMIME on From and To and the hilarity that ensues for forwards,
the primary user of ContentAsMIME.

The correct solution for From and To will be to use the encoding logic
in 4.2-on-4.0/protect-more-chars-while-decoding-headers once it is merged.

[1] http://issues.bestpractical.com/Ticket/Display.html?id=19125

The fake methods were returning the object instance itself, rather than
a data type compatible with what the real object does.  While this does
not cause any bugs at this point, it could lead to unexpected
consequences in the future; for example anything calling headers_out in
an array context would break, even though it's a valid thing to do.

RT::Extension::ActivityReports makes a call which requires the fake web
request object to implement this method.  [rt3 #20871]

Both Outlook and Lotus render <script> tags poorly, so they're useful to
remove.

This resolves part of CVE-2011-2083.

Some tests were adjusted for this change.

->add always adds new occurences instead of overwriting existing ones.

    ...and for less indentation :)

    This was painful to figure out :| ->debug can return false which
    makes that statement not return even though that was the intent.