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.
Merge branch '4.0/extensible-ticketsql-cf-limits' into 4.0-trunk

Conflicts:
	lib/RT/Tickets.pm
	share/html/Search/Build.html