Make transaction CFs correctly limited to the correct queues

In 74e6f62, the $queues{...}++ line was moved from above the "next
unless ..." line to below it.  This changes the meaning of %queues, from
"the set of queues of the tickets listed" to "the set of queues of
tickets _changed_."  This causes the transaction CF list to be broader
than expected in most cases.

Make the transaction CFs limited based on $seen_queues, which is
computed based on all tickets listed, and remove the no-longer-used
%queues.

    (cherry picked from RT commit 3a4ce59eabbd89f77f6d48efa38bfbe968b28dc5)
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

    (cherry picked from RT commit a9ae79a1ee31dff81b9712493da1cf9bbd39f488)
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.

    (cherry picked from RT commit eb7dff164d3a37da0da73ca414c37fb91f42c4ba)
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.

    (cherry picked from RT commit d39521de41ec430ddcaab92f7efbad0d93de77ac)
case-insensitive compare for built-in statuses
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).

    (cherry picked from RT commit daf0a6c18f1ef822349e1d89d12be827b356d02e)
Add callbacks for before and after the query builder criteria picker

    (cherry-picked from RT commit 94aeca9f47f7923b8fe82c02e02d7f9e892716a7)
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.

    (cherry picked from RT commit 565b40eaf184d846c20da315b5247fd7c86c2e17)
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.

    (cherry picked from RT commit 228451ce0c60bac20bf329d0896c7312db3af318)
order query parameters ourselves to avoid random ordering on perl-5.18+

t/web/walk.t might test the same pages(only query params ordering differs) for
multiple times without this.

it's also more right if we show consistent urls.

    (cherry picked from RT commit ee0712ae5cb0f9097ba2f68e97491589636f88c2)