Avoid "Exiting eval via next" warnings

These aren't currently triggered by any tests, but occur if objects are
referred to by Name in the database instead of id and records support a
corresponding ColumnNameObj method.
Set the new status *after* setting the new queue in RT::Ticket->SetQueue

This removes the need for an ugly caller() check in ValidateStatus to
force pass if the callstack contains SetQueue anywhere.  The behaviour
for Status now matches the other updates which depend on a successful
queue change first.
Rename RT::Queue->Lifecycle to LifecycleObj for consistency

All other columns which reference other records use ColumnName for the
database value and ColumnNameObj for the inflated object.  Mimic the
same methods in RT::Ticket as well to avoid confusion, despite
RT::Ticket not having a Lifecycle column itself.

This reverts a small part of e904afe which added special handling for
the Lifecycle column to RT::Record->Update.  With the existence of a
LifecycleObj method, the previously existing Name handling works
correctly.

A usage of $QueueObj->Lifecycle in share/html/Admin/Queues/Modify.html
is left as-is to fix a bug: the intention was always to use the
lifecycle name as the current value, but instead an object was passed to
share/html/Widget/Select:InputOnly.  Mason helpfully coerced the object
into an array, which by happenstance led to the correct behaviour.
Refactor Lifecycle methods and behaviours into roles

The first use of roles in RT!  With support for extensions adding
lifecycles on arbitrary object types, it's extremely useful to abstract
the common behaviour patterns into roles that can be consumed by many
classes.

Role::Basic provides a very straightforward implementation without the
prerequisite of shoehorning all our classes into Moose's view of the
world.  The most notable missing feature is parameterized roles.
Instead, roles can require a method in the consuming class which returns
the value of the "parameter".  This does limit individual role
application to one-per-class instead of potentially many instances of
the same parameterized role, but it is a sufficient workaround for now.
RT::Lifecycle->Type accessor

Stashes the "effective" type of the lifecycle at the top level of the
object, including for virtual aggregate lifecycles (i.e. lifecycles
loaded with no name, only a type).  In cases when a lifecycle is
requested by name with a type that conflicts with reality, ->Type will
return the requested type, not the *declared* type of the lifecycle from
the config.  This ensures ->Type matches the blessed lifecycle class;
hence the "effective" type.
Refactor ticket Status methods and behaviours into a role

A few error messages have changed slightly, but most behaviour is
unchanged.  The most notable change is that tickets now record a Status
transaction when the Status is automatically updated (via lifecycle
maps) after a queue change.
Setup RT::Record's base classes before use-ing subclasses of itself

RT::Record was attempting to load and compile subclasses of itself before it
had declared its own base classes.  This meant those subclasses were missing
all of the RT::Base and DBIx::SearchBuilder inherited methods at compile-time.

Since by run-time everything was hunky dory, the ordering bug flew under the
radar until Role::Basic introduced compile-time method checks on RT::Ticket and
RT::Queue.  As it happens, those classes get loaded (quite indirectly) when
RT::User is use-d.

Module::Install::RTx::Factory ran face first into the bug (during `make
initdb`) when attempting to require RT::System individually (which loads
RT::Record as a base class, which loads RT::User, et cetera).

Normal RT initialization didn't trigger the bug because RT::CurrentUser is
loaded before RT::System in RT::InitSystemObjects().  RT::CurrentUser loads
RT::User by way of a base class, which loads RT::Record by way a base class,
which is able to finish compiling and setting up its parents before RT::User
finishes loading the dependency chain which eventually invokes Role::Basic.

The general bug is loading subclasses of yourself before declaring a base
class, and it appears RT does that in a number of classes.  Another commit
fixing those is forthcoming.

The extra "use RT;" line is necessary since we're relying on RT->Config
at compile-time in the first "use base" line.  If RT.pm is already
loaded, as in normal system initialization, it'll do no harm; if RT.pm
isn't loaded already, it'll load it up to avoid a compile error.
Always declare base class before use-ing other RT:: classes

This will help avoid weird, hard to track down load ordering bugs in the
future.
Move RT::Record dependencies to runtime, not compile-time

Some of the "use RT::Foo" modules listed in RT::Record are themselves
subclasses of RT::Record.  This means that RT::Record's methods are not
necessarily initialized before the subclasses are loaded.  In tern, this
causes the methods of RT::Record itself to be invisible to Role::Basic's
"with" -- though methods of its superclass (DBIx::SearchBuilder::Record)
are, as hey are pulled in earlier by the compile-time "use base" above.

Move the import of RT::Foo classes to runtime, not compile-time.  This
simplifies load order during compile-time, ensuring that a class loads
all of its parent classes and roles without possibly creating load-order
loops.  This also requires that any roles also declare their module
dependencies using "require" as well.  As there are no notable "import"
methods to RT's object classes, and (save for Role::Basic method
resolution) compile-time checking is necessary, this is safe.
Merge branch '4.2/lifecycle-roles'

Conflicts:
	docs/UPGRADING-4.2