Only treat ">" as an email quoting character

All of the other defaults (!, #, %, =, |, :) cause too many false
positives and hardly any true use as a quote character.
Escape { and } in regexes when used as literals

Perl 5.17.6 (on the path to 5.18) deprecates and warns quite noisily
about unescaped braces.  RT's dependency chain isn't fully clean of this
warning, however...
File::Temp under 5.18 warns if passed an undefined template

File::Temp does not require that a defined template be provided -- if an
even number of arguments is passed, an undef template is assumed.  This
has been true for all versions of File::Temp, so does not break
backcompat.

Explicitly passing an undef template causes "Use of uninitialized value
$_[0] in string eq" warnings on 5.18, so skip doing so.
extract our code that fetches table names

keep function private, so far we use it in upgrade
scripts and tests.
require newer DBD::Pg on Pg 9.2 for upgrade

We use DBI's table_info method in upgrade scripts.
It fails on Pg 9.2 with old DBD::Pg driver. We don't
have to bump required version for all Pg users, but
can help users of Pg 9.2 to solve the problem by
providing better error message.
REST fix: show updated message as long as the object is updated.

previously, we only check if the last update succeeded or not, which is not
that right.

without this, t/web/command_line.t will fail on perl 5.18.0 because of the new
*random* results of hash's keys().
compare ref type first to make sure $entry_ref is not weirdly overloaded

one snippet:

    use Math::BigInt;
    no strict 'refs';
    # $round_mode = bless( do{\(my $o = 'even')}, 'Math::BigInt' );
    my $round_mode = *{'Math::BigInt::round_mode'}{SCALAR};
    print 'ok' if $round_mode;

because Math::BigInt overloads "bool" operation, the "if $round_mode" dies
with message "Not a HASH reference".

we do similar GLOB thing in RT::Config::__GetNameByRef, but before perl 5.18,
we can always find the right Name before checking "Math::Big::Int::round_mode"
thanks to the consistent hash's keys() behavior.

hash's keys() behavior has been changed since perl 5.18:

   Hash randomization
    The seed used by Perl's hash function is now random. This means that the
    order which keys/values will be returned from functions like "keys()",
    "values()", and "each()" will differ from run to run.

i.e. we might reach "Math::Big::Int::round_mode" in RT::Config::__GetNameByRef
since perl 5.18, so we need to make sure it won't die, that's the reason we do
the extra check before the "bool" operation("next unless $entry_ref;")

Math::BigInt is require by GnuPG::Interface.
Merge branch '4.0/more-conservative-quote-folding' into 4.0-trunk
Allow CustomFieldLookupType to be called as a class method

(cherry picked from commit 1ff3f2b0a97d1e336ced7542ce2b0201ff5309fc)
Add an ObjectTypeFromlookupType method and document RecordClassFromLookupType

RecordClassFromLookupType is useful when joining to ObjectCustomFields,
but there wasn't an existing method for code that wants to join to
ObjectCustomFieldValues, so we can borrow the code and tweak the regex a
bit.
ObjectType/RecordTypeFromLookupType as class methods

Where LookupType must be passed as an argument.
Refactor part of LimitToGlobalOrObjectId into LimitToObjectId

Useful when you only want to find CFs applied to a certain object and
not global ones too.
Rename some variables that will become confusing.

As these join aliases start to refer to transaction cfs and not just
ticket cfs, it is really weird to have everything named TicketCFs
Decipher TicketSQL CF identifiers using a passed in LookupType

The LookupType is necessary to find the correct CF by name, as well as
to support the arcane CF.ObjectId.{CFName} syntax, for arbitrary object
types (not just ticket CFs on RT::Queue).

Potential syntax made possible, for example:

    TxnCF.{CFName}
    TxnCF.Queue.{CFName}
    ArticleCF.Class.{CFName}

The CF lookup behaviour of CF.Queue.{CFName} changes slightly due to
changes in which custom fields API is used.  Most notably, such syntax
previously exhibited the following behaviour but no longer does:

    • Disabled CFs could be found if no enabled CFs matched.
    • The existence of multiple matching CFs with the same name (& within
      the same queue) was ignored; the first was the only one used.

As CF.Queue.{CFName} is fairly arcane syntax, these changes shouldn't
affect most usage of TicketSQL.  It is unlikely that anyone using the
extended syntax is intentionally relying on any of the discontinued
behaviour noted above.  Disabled CFs, even if found, are eliminated from
results by later code.  The two behaviour changes are effectively bug
fixes.

A case-sensitivity difference between CF.{Name} and CF.Queue.{Name} is
preserved by checking which syntax was used.  This is bending over
backwards solely for the sake of compatibility within the 4.0 series.
It is conceivable that someone is relying on it, knowingly or not, and
it is easy enough to replicate.  In 4.2, we should remove this
distinction.
Refactor _CustomFieldJoin to take a LookupType

… so that we can join to the correct table if not Tickets.  An
extensible data structure is introduced to determine how to join CFs to
applied objects.

This lets _CustomFieldJoin handle joining for transaction CFs or other
CFs which may want to be searched.
Refactor _CustomFieldLimit to use a LookupType in %FIELD_METADATA

Potential new search clauses, such as searching transaction CFs, want to
match all the different ways that ticket CFs can.  It makes sense to
just wrap the limits in a LookupType change (especially since
_CustomFieldLimit happens to be recursive for IP and Date searches).
Fix horrendous load order of shredder tests

They started failing because of an added
RT::Ticket->CustomFieldLookupType call.

The RT::Ticket load order is also awful and doesn't setup it's base
class until very late, including after importing other packages.
Add callbacks for before and after the query builder criteria picker
PickTicketCFs refactored from the now-generic PickCFs

PickCFs may now be used for other types of CFs.  Callback semantics
remain the same, so no extension using the callbacks in PickCFs will be
broken.
Parse FooCF.{Bar} when adding a TicketSQL clause in the Query Builder

Extends the parsing from a strict CF.{…} to SomeOptionalWordCF.{…}

In an ideal world we programmatically build up what's recognized from a
data structure like %RT::Tickets::FIELD_METADATA, but that requires more
refactoring than we're up for in a stable series.