Ensure that Date and DateTime CF values validate using current values

Date and DateTime CFs, for historical reasons, do not place their
defaults in the CF entry box.  Thus, and update where no value is
submitted for such a CF is equivalent to leaving that CF unchanged.
While the CF update code (see RT::Interface::Web line 3088) implements
this, the vlaidation code was not aware.  Thus, a "mandatory" date CF
would not pass validation if left unchanged.

In RT 4.0, this led to silent errors on the Modify page, and did not
prevent other updates.  In RT 4.2, thanks to 16ddc81, failing to enter
the current value explicitly into Date and DateTime CFs causes them to
fail to validate, and thus prevents all other updates of the page.

Alter the validation code to be aware that Date and DateTime CFs, if
empty, should take their values from the current CF values.
Make validation code aware that 1970 for date CFs is "not set"

For the purposes of CF validation, 1970-01-01 is equivalent to no OCVF
value.  Thus, entering 1970-01-01 as a Date value should only be allowed
if the CF is not mandatory.
Use defined-or instead of || to not lose "0" as a CF value for validation

The value "0" for a Date or DateTime CF is also equivalent to
1970-01-01, and thus invalid for mandatory CFs.  However, due to the use
of || rather than //, the CF was viewed as "empty" and thus was
validated against its _old_ value, and not the "not set" value.
Replies with the rich text should quote an HTML part using <blockquote>

The gmail_quote class is semi-standard, and occasionally aids in
display.
Ensure that plaintext signatures are escaped correctly before being appended

We use specific escaping, rather than EscapeHTML, because the
signature-detection code in RT::Interface::Web::StripContent assumes
that the signature was transformed into HTML by CKEditor; as such, to
ensure that no-data messages are detected as before, use the same
transformations here.
Logic simplification
Add styling hints to <blockquote>-quoted sections
More liberal signature detection in HTML mail

Some examples of signature insertion in various clients:

GMail:
  [...]</div>-- <br><div dir="ltr">This is my <b>bold</b> signature!</div>

Thunderbird:
  [...]
  <div class="moz-signature">-- <br>
    This is my <b>bold</b> signature!</div>

Apple mail does not insert sigdashes by default.  When added by hand,
they are implemented via:
  [...]</div><br><div>
  <div style="[snip]"><div>--&nbsp;</div><div>This is my<span class="Apple-converted-space">&nbsp;</span><b>bold</b>&nbsp;signature!</div></div>
  </div>
...which is difficult to catch without false-positives.

Unfortunately, Evolution uses:
  [...]<BR>
  <TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
  <TR>
  <TD>
  -- <BR>
  This is my <B>bold</B> signature.
  </TD>
  </TR>
  </TABLE>
...which is much more difficult to extract, as the whole table would
need to be stripped.
Trim HTML in replies to the contents of the <body> tag

Email clients vary as to if they attempt to provide a full HTML document
(starting with doctype and <html>), or merely an HTML-formatted snippet.
Content which contains an <html> tag unfortunately interacts poorly with
CKEditor when shoved inside a <blockquote>, effectively imediately
closing the blockquote.

Pass content to quote through an HTML scrubber to remove the offending
<html> tags, the <head> tag, and and any <meta> contents thereof.
Allow searching for dates which are unset

e60885aa changed the meaning of "Starts < 'today'" (and all other date
limits) to no longer include tickets whose dates are unset.  This
behavior change also made it imposible to search for such tickets, as
"Starts = '1970-01-01'" would also no longer find them, and the more
straightforward "Starts IS NULL" was invalid.

Allow IS NULL and IS NOT NULL searches on date ranges.
Add an UPGRADING note about the changed meaning of < in date limits
Pass Heavy => 1 to InitClasses to enable error checking

8976c535 erroneously claimed that it was replacing a clone of RT->Init,
but missed that RT->Init doesn't call InitClasses(Heavy => 1) but
standalone_httpd did.

When standalone_httpd and rt-server were mashed together during the
PSGIfication, Heavy => 1 had already been removed. Sadly - the other
Heavy => 1 usage in webmux.pl was lost in e1c6d4a8c.

This means that no version of RT 4.0.x or 4.2.x has checked if your
Scrips had a valid Condition and Action, or checked your classes in
CustomFieldValuesSources.  It also misses the pre-loading we were trying
to do for the sake of mod_perl (21f181dd).

It's likely the CustomFieldValuesSources check could go in a
PostLoadCheck, but the Scrips code would need to keep living here.
The LoadLexicons which was also added for caching (21f181dd) was removed
a month before all the Heavy code broke in order to improve test
performance 5f2799c5, it's unclear if it should come back in some cases.
Ensure that "Show quoted text" always displays on its own line
Drop disallowed "pending -> delivered" action

The transition map does not allow such a transition.  Resolves issues
bug #28238
Merge branch '4.0/restore-heavy-initclasses' into 4.0-trunk
Merge branch '4.0/lifecycle-example' into 4.0-trunk
Add some simple tests for IS and IS NOT NULL
Allow IS/IS NOT with LimitDate, by providing DefaultEA for them

%DefaultEA only matters for the old Restrictions clauses; regardless,
permit the new format there, for consistency.
Merge branch '4.2/date-is-null' into 4.2-trunk
Don't print anything to STDOUT during ACL granting

When run under the web installer, output to STDOUT is displayed in the
browser.  This led to "Granting access to ..." being displayed atop the
menu during the database initialization step.

MySQL is the only database type whose ACL tries to display output when
successful. As 'rt-setup-database' provides sufficient updates as to
what is going on, an the specific GRANT being run is mostly irrelevant,
omit the warning entirely.  Switch to using the existing logging
infrastructure for the true warnings.