Provide a default value for Category on External CFs

If the hash passed to ->LoadFromHash does not contain a key for
category, any code which later calls ->Category on the object will turn
around and attempt to ask the database.  This is precisely what
EditCustomFieldSelect does, of course.  For External CFs, this is both
slow _and_ wrong -- it will always ask for CustomFieldValue id #1, and
will do so repeatedly, for every external CF value provided.  This
incurs a significant performance penalty on ticket creation and updates,
as listing the full set of external values suddenly incurs hundreds of
extraneous database queries.

Ensure that a value for category exists for all external CFs, to save
the erroneous trip to the database.
Allow downloading 0-length files if they have a name

Resolves I#9050
Link docs/foo.pod in README to the appropriate place

Fixes I#21444.
Allow searching on remaining user location fields

These fields became illegal in 1042719; add them back, as they do not
present a security risk.

Resolves I#26960.
Updated translations (de, el, sk)
Partially revert 487df4d92f0dcc6fd197e60b99719fcbe979cbcc

Switching directly from Queue to ObjectId is not correct, as it fails to
provide the ObjectType/LookupType hint.
Allow, and document, passing LookupType and ObjectId in @ACL
Test of the Queue/ObjectId failures

These tests are based on the RTIR initialdata file which identified the
problem and fail on 4.2-trunk because of warnings generated during the
initialdata load of t/api/initialdata.t

I suspect we want to enhance our initialdata sample with any further
Handle::InsertData hacking (or docs/initialdata.pod updates).
Merge branch '4.2/initialdata-cf-acl' into 4.2.5-releng
->Content is as formatted for the user, not the DB value

When comparing the canonicalized values, one must bear in mind that
->Content is not just the Content column in the database; instead, it
falls back to the LongContent, in addition to doing explicit formatting
for IP range custom fields.

Compare the 'Content' key to what is actually in the 'Content' column,
using $self->_Value().  This does not fix IP custom field updates, as
the input Content has still not been split into Content and LargeContent
as the database stores it.
Add a generic ->_CanonicalizeValue

Refactor the two places that use can() into a common method.
Move canonicalization into RT::ObjectCustomFieldValue->Create

Previously, value canonicalization happened for dates and datetimes in
RT::CustomField->AddValueForObject, and for IP addresses and ranges in
RT::ObjectCustomFieldValue->Create.  Standardize on the latter, as it is
lower down and thus harder to skip accidentally.

This requires creating the CustomField object as the current user, not
as the system user, as Date and DateTime canonicalization cares about
the time zone of the current user.  This, in turn, requires switching to
_Value('Type') instead of Type, as the constructed $cf object is not
guaranteed to have the right context objects for it to be readable by
the user.
Add common IP address and range canonicalizers

The IP address and range canonicalization in ObjectCustomFieldValue's
Create is moved into the more general canonicalization functions.  This
also allows HasEntry can split IP ranges correctly to check their
existance, and ensures that the standard form (padded to three digits
per octet) is compared against the database.
Let canonicalization return a failure message

This allows CF creation to abort on invalid values, and HasEntry to give
up and move on if passed a value that can never be found in the
database.
Provide a better error message for loading OCFVs on an invalid CF
Canonicalize all OCFVs on load, not just IP address ranges

This ensures that IPs are padded to three digits per octet, and that
dates are formatted in standard ISO time.
Remove too-many-value OCFVs by id, not Content

This merely serves to bulletproof the removal step; there is no need for
the more expensive Load with Content.
Reuse existing validation in OCVF canonicalization

Rather than reiterate the logic in the canonicalization functions, use
the error condition they return to determine the validation error.

This also opens the door for invalid date and datetime fields to abort
ticket updates, by providing a validation error if they do not parse.
For backwards compatibility, this does not enforce such.
Remove a needless block; ParseIPRange does the exact same as its first step
Merge branch '4.2/ip-address-canonicalization' into 4.2.5-releng