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
Revert "Provide a better error message for loading OCFVs on an invalid CF"

This reverts commit 404787322dffbf7faa13f43a3ad9ff0691ea6b55.

The CF object may not be readable without context.
Upate localizations

 - Updated Lithuanian translation

 - "Content is an invalid IP address" has been renamed to
   "Content is not a valid IP address"

 - "Input can not be parsed as an IP address" has been dropped.
Merge branch '4.2.5-releng' into 4.2-trunk