logind: track user service managers as 'manager' session class

logind: track user service managers as 'manager' session class

Previously, all user code was part of a session except for the code run
as part of user@.service, which wasn't. This tries to make this more
uniform: we'll track the user@.service runtime also as a session, but of
the special type "manager".

This means we have a really good overview finally of all user code that
is running and can make decisions on what to start when and how long to
keep it around. The pam_systemd client side will now be reasonably
uniform: it just calls the CreateSession() bus call with the right
class, and we'll return any data it needs. This means the weird
"side-channel" we previously used to initialize XDG_RUNTIME_DIR for the
user@.service goes away (see next commit).

This conditionalizes various behaviours now cleanly depending on the
session class:

1. SESSION_CLASS_WANTS_SCOPE() will be true for all classes except for
   the manager class. It declares whther the client shall be migrated
   into their own scope, which we generally want for sessions but not
   for the manager, since it already has its own service unit.

2. SESSION_CLASS_WANTS_SERVICE_MANAGER() will be true for all classes
   except for the manager class. It declares whether we shall start the
   service manager if a session of this class is around. Of course, this
   is off for the service manager, since this would always pin itself.

3. SESSION_CLASS_PIN_USER() will be true for all classes except for the
   manager class. It declares whether the we shall keep the User
   structure around for a user as long as the session is around.

Now you might wonder why have these as three functions, even though they
mostly give the same answers?

That's because this all is preparation to add further session classes
later that will return different answers for the three calls. (For
example, a later patch adds "background-light" which will return true
for SESSION_CLASS_WANTS_SCOPE() and SESSION_CLASS_PIN_USER(), but false
for SESSION_CLASS_WANTS_SERVICE_MANAGER(). i.e. it will get a scope, and
pin user tracking, but not start a service manager.