logind: fix SetLinger to authorize by client's effective User ID

logind: fix SetLinger to authorize by client's effective User ID

SetLinger is authorized by the PolicyKit action "set-self-linger", if it is
not passed an explicit UID.

According to comments we were determining the default UID from the client's
session.  However, user processes e.g. which are run from a terminal
emulator do not necessarily belong to a session scope unit.  They may
equally be started from the elogind user manager [1][2].  Actually the
comment was wrong, and it would also have worked for processes
started from the elogind user manager.

Nevertheless it seems to involve fetching "augmented credentials" i.e.
it's using a racy method, so we shouldn't have been authenticating based
on it.

We could change the default UID, but that raises issues especially for
consistency between the methods.  Instead we can just use the clients
effective UID for authorization.

This commit also fixes `loginctl enable-linger $USER` to match the docs
that say it was equivalent to `loginctl enable-linger` (given that $USER
matches the callers user and owner_uid).  Previously, the former would not
have suceeded for unpriviliged users in the default configuration.

[1] It seems the main meaning of per-session scopes is tracking the PAM
login process.  Killing that provokes logind to revoke device access.  Less
circularly, killing it provokes getty to hangup the TTY.

[2] User units may be started with an environment which includes
XDG_SESSION_ID (presuambly GNOME does this?).  Or not.