This will help avoid weird, hard to track down load ordering bugs in the
future.

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.

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.

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.

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.

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 e904afe2 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.

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.

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.

Conflicts:
	share/html/Admin/Articles/Classes/Modify.html
	share/html/Admin/Groups/index.html
	share/html/Prefs/Quicksearch.html
	share/html/Ticket/Elements/Reminders
	share/html/Ticket/Elements/UpdateCc

Conflicts:
	share/html/Elements/ColumnMap

Conflicts:
	docs/UPGRADING-4.2
	etc/RT_Config.pm.in
	lib/RT/Squish/JS.pm
        share/html/m/_elements/header

The conflict in RT_Config.pm.in was due to JS files which were added
since the branch branched; these new files have been added into
RT::Interface::Web->JSFiles accordingly.

One additional call site of ->Get('JSFiles') in m/_elements/header was
also added since the branch branched; adjust it to call
RT::Interface::Web->JSFiles.

Conflicts:
	t/api/date.t

Both RT::Ticket and RT::Queue's AddWatcher method attempt to resolve the
passed-in email address in order to ascertain if it has appropriate
permissions.  This requires duplicating code in _AddWatcher (now found
in AddRoleMember).  In the case of RT::Queue's AddWatcher code, this
also effectively prevented passing in not-yet-in-the-database email
addresses, as ACLs were checked with ->Load, despite _AddWatcher later
using LoadOrCreateByEmail.

Provide a hook in AddRoleMember after the principal has been resolved,
which can be used to apply ACLs.  This also removes the need for
separation between _AddMember and AddMember.

RT::Ticket and RT::Queue contain very similar code in _AddWatcher, which
attempts to check IsRTAddress and resolve the passed email address to a
user, creating it as necessary -- though RT::Queue's implementation
predates ->LoadOrCreateByEmail.  This should not be surprising, as the
code in RT::Queue was copied wholesale from RT::Ticket in 40b1ea0b.

Unify the two divergent codepaths by pushing additional the additional
logic down into RT::Record->AddRoleMember.  This also serves to resolve
a bug when AddRoleMember was called with a non-existant email address.

Make use of the new methods surrounding roles in the ticket merging
code.

b2f96213 generalized _CreateTicketGroups and refactored it into
RT::Record's _CreateRoleGroups.  Unfortunately, _CreateTicketGroups was
mistakenly re-introduced during the merge from 4.0-trunk in 1fbb6329.
Remove it, again.

This provides the most sane default that we can; if sendmail or
equivalent is not installed, outgoing mail will trigger RT to record
the "cannot send outgoing mail" transaction.

The 'smtp' delivery mode, despite being supported, was a poor choice of
delivery, as in the case where the chosen sever failed to respond, it
would silently drop the message.  Remove the option, so that this does
not bite users.