Let you Quick Create in Queues that don't define the new status

Since we don't offer Status in the Quick Create widget, we should just
let Create pick the on_create default from the Queue's lifecycle.

While in here, update RT::Ticket::Create to have less lying around what
to pass for Status (valid statuses haven't listed been in
RT::Queue in 4.0 or 4.2).

We started using the default from the Queue's Lifecycle in b206b50a,
which is the same commit where we stopped hardcoding 'new' in
RT::Ticket::Create.

Found in RTIR user since 3 of the 4 RTIR queues don't allow tickets
with the new status.
->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
GraphViz.pm does not depend on the libgraph.so, but rather the "dot" program

This allows `configure` to better detect when GraphViz will be able to
be installed smoothly.  It may cause additional dependencies on an
upgrade -- however, failing to install these dependencies will not
change RT's behaviour in any way, as the --enable-graphviz option merely
controls default dependencies.  Enabling and disabling of the feature is
done at startup time, based on the presence of the GraphViz module or
the $DisableGraphViz configuration option.

This also makes RT's `configure` no longer require a working gcc.
Confirm user object when checking _WithoutTickets

When shredding users, check the user object before processing
_WithoutTickets. If it's not properly loaded, return to allow
FilterWithoutTickets to skip that user and continue processing.

This should only happen in strange cases, like using the
MergeUsers extension where one user record can try to load
another user record that shredder has already deleted.
Update warning to be more informative, and downgrade to info
Merge branch '4.0/check-user-object-in-shredder' into 4.0-trunk
Merge branch '4.0/stop-hardcoding-new' into 4.0-trunk
instructions for how to add new global status

In pre 4.0 versions, adding new statuses was documented well enough with

http://bestpractical.com/docs/rt/3.8/RT_Config.html#ActiveStatus-InactiveStatus

but with lifecycles this is no longer valid and there is no documentation
on how to achieve this.
Merge branch '4.0/new-status-pod' into 4.0-trunk
Merge branch '4.0/graphviz-detection' into 4.0-trunk