Confirm loaded queue object before setting context object

For cases where an invalid Queue value is passed as an arg,
either a name or id of a non-existent queue or even 0, previously
the emtpy queue object would still be set as the context object
even though the load failed. This caused the search to add a
Limit on a LookupType of RT::Queue, which won't find any
custom fields.

Check the return code to avoid setting the empty queue object and
to warn so there is some help in the logs to track down a possible
typo in the queue name/id.
Explicitly exclude 0 from queue lookup

A Queue value of 0 represents a global CF, but will not load a
queue successfully. Explicitly exclude 0 from the queue load and
context object setting. Although 57e10bf9 will now prevent this,
it logs a warning that is inappropriate when using the documented
API for the method.
Tests for LoadByName with queue 0
These statements simplify to "skip if the queue is undef or 0"
Short-circuit if a bogus Queue was passed
Simplify logic by loading the queue even if not strictly necessary

The existing logic in the "if" statement serves to skip the block in
precisely one situation -- the passed Queue is numeric, and there
already exists a ContextObject.  In such situation, it is not necessary
to attempt to load the Queue -- but it is not harmful, either.  In fact,
it may allow a better warning in cases where a numeric but non-existant
Queue is passed in.  It also clarifies the logic immeasurably.
Move LookupType defaulting earlier

We will use the LookupType as a default in the next commit, and thus
need to have it prior to when we resolve the object (currently Queue).
Allow for non-Queue context objects

This opens the door for using LoadByName for custom fields not on
Transactions, Tickets, or Queues.  Callers specify a LookupType and
ObjectId, from which the class to load (if not RT::Queue) can be
inferred.  Consequently, using LoadByName for User (or Asset) custom
fields no longer requires writing an alternate and parallel
implementation of LoadByName.
Allow callers to not get disabled CFs

For backwards compatibility, LoadByName has always maintained the
property that it may return a disabled custom field -- though it does so
only if there are no matching enabled fields.

Provide an option to control this behavior; the default is maintained as
it was previously, for backwards compatibility.

Note that previously, the only OrderBy was the Disabled flag -- this
means that if there were two non-disabled custom fields with the same
name, which one was returned was possibily non-deterministic.  This
commit places a predictable ordering on the resolution; namely, lower
SortOrder and lower id take precedence.
Allow callers to look in Queue and global CFs

Previously, in order to respect global CFs, callers were forced to
explicitly attempt to LoadByName with a queue, and then attempt again
with Queue => 0 if it failed.

Provide an option, defaulting to off, to first search queue CFs,
followed by global CFs.
Optimize the query slightly, by eliminating an unnecessary DISTINCT

The join from CustomFields to ObjectCustomFields is guaranteed to be
distinct, by dint of the fat that either it is global, or it matches the
objectid we desire; as such, we can eliminate a cumbersome DISTINCT by
informing DBIx::SearchBuilder of this property at JOIN time.
Document but deprecate the old names for LoadByName

While it is tempting to officially deprecate these, they are in use in
core RT and in extensions, and introducing new deprecations during a
stable series is unwise.  Suffice to document them as deprecated, and
migrate exsting uses away from the, though not produce deprecation
warnings.
Add tests for the new LoadByName functionality

This throughly exercises the new codepath.  It leaves the existing
t/customfields/api.t untouched, though it may be sensible to merge them
in the future.
Switch existing code to using LookupType with LoadByName, to be explicit

To set an example for future code, transition away from the 'Queue'
argument, in preference to LookupType and ObjectId.  This helps clarify
the type of custom field that is expected to be returned.
Simultaneously, switch to using IncludeGlobal where the code would
benefit from such.
Merge branch '4.2/confirm-loaded-queue' into 4.2-trunk