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.
Don't alter @statuses when escaping

The existing line to escape statuses altered @statuses in the process,
causing ->IsValid() to return false on the escaped versions, and thus
failto display any statuses which contained quotes or slashes.  Store
the escaped versions in a different variable, to ensure that un-escaped
status names are passed around everywhere, and only escape them
as-needed.

Fixes I#29056.