Merge branch '4.2/new-default-options'

Conflicts:
	docs/UPGRADING-4.2
Merge branch '4.0/search-tickets-by-queue' into 4.0-trunk
Merge branch '4.2/skip-validating-unsubmitted-cfs'
Remove SMTP delivery option, which can drop email

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.
REST: delete CF value rather than add when value is empty

AddCustomFieldValue doesn't handle empty case, caller should
take care. If we don't then RT records that an empty value
was added
Check and warn at load-time if "smtp" was set as the $MailCommand
Fall back to sendmailpipe on unknown $MailConfig settings

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.
Move "testfile" logic to where other custom Mail::Mailer types are configured
Automatically add or remove "-t" from $SendmailArguments
Note removal of 'smtp' $MailCommand option in UPGRADING-4.2
Remove old method re-introduced in mismerge

b2f9621 generalized _CreateTicketGroups and refactored it into
RT::Record's _CreateRoleGroups.  Unfortunately, _CreateTicketGroups was
mistakenly re-introduced during the merge from 4.0-trunk in 1fbb632.
Remove it, again.
Simplify ticket merging code for roles

Make use of the new methods surrounding roles in the ticket merging
code.
Push logic into RT::Record->AddRoleMember from _AddWatcher

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 40b1ea0.

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.
Reduce duplication by placing ACL callback in AddRoleMember

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.
Consolidate DeleteWatcher code into DeleteRoleMember, similarly
Factor out common _HasModifyWatcherRight code
call DeleteCustomFieldValue instead of OCFV->Delete

we were loosing history on the ticket because such direct
call as transactions on ticket are not created
drop OCFV->Delete, AddCustomFieldValue takes care

This code branch is for CFs with one value only. We
can just call AddCustomFieldValue and it will do the
right thing.

Without this change history is incorrect as transactions
say that new value has been set instead of value change.
test CF changes via REST
just call AddCustomField value

We do report that "something" was already the current value for
other fields (eg. Status), so I don't see reason to handle it
specially for custom fields.