->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.0/ip-address-canonicalization' into 4.0-trunk