Use cached attribute list when fetching preferences

Attributes have, since their initial implementation, use
LoadByNameAndObject.  However, when the user does not have any
preferences stored, this can be very expensive, as
DBIx::SearchBuilder::Record::Cachable does not cache negative results --
that is, that the matching Attribute row does not exist.  This means
that every request for RT->Config->Get( '...', $session{CurrentUser})
results in an identical database query.

Use the ->Attributes method, which caches the set of user attributes.
This, in itself, is not sufficient to cause the preferences to be
cached; the the next commit.
Cache Attributes on the CurrentUser object, not an ephemeral User object

The previous commit moved preferences to using the Attributes cache;
however, this gains little because the cache is on the User object
derived from the CurrentUser, which is derived afresh each time that
RT->Config->Get() is called.

Call the ->Preferences method directly on the CurrentUser, instead of
the desrived User, so the cache is on the more durable CurrentUser
object.  The cache is cleared (via ->ClearAttributes) during the ->Load
call at the start of every request.  ->DeletePreferences is also
switched to use ->DeleteAttribute, which explicitly purges the cache;
otherwise, it may return stale data.

This better attribute caching ensures that even negative preferences
loads are cached for the duration of the request.  This, in turn,
eliminates a large number of repeated database queries (such as for the
username format preference) for users with no explicit preferences set.
Merge branch '4.0/cache-empty-preferences' into 4.0-trunk