When possible, switch to IN or NOT IN rather than multiple OR'd clauses

DBIx::SearchBuilder 1.63 began allowing the IN and NOT IN operators; RT
4.0 could not immediately make use of them because it did depend on a
high enough version of DBIx::SearchBuilder.  RT 4.2, however, depends on
DBIx::SearchBuilder 1.65, and thus can use IN freely; this is
advantagous because query planners can make better choices with IN than
with long boolean queries.

Unfortunately, DBIx::SearchBuilder 1.65 does not respect the
CASESENSITIVE => 0 option when passed OPERATOR => 'IN'.  This is only an
issue on the limits for Group.Name, which must be case-insensitive.  To
work around this, pass FUNCTION => 'LOWER(?)', VALUE => [an lc'd list],
and CASESENSITIVE => 1.  The former two deal with making the search
case-insensitive, while the latter quiets the warnings which attempt ot
detect case-sensitive searches on Group.Name.

This also rewrites two queries in GetForwardAttachments into one, using
a simple JOIN.
Merge branch '4.2/use-in-operator' into 4.2-trunk