The assertion message suggests that it should be able to be bypassed by
specifying a valid service directory, however that is not the case.

Fix the assertions, so that they can be bypassed by specifying a valid service
directory.

During the PAM conversation, `pam_gnome_keyring` will try to unlock the
login keyring. If the keyring created by gnome-initial-setup hasn't
changed ownership, then `gnome-initial-setup-copy-worker` can't move it
in place and `gnome-keyring-daemon` will try to create a new login
keyring. This either means the keyring created in g-i-s is lost or g-k-d
gets confused about a keyring that shows up after initializing but
before it's received the unlock/create request.

Similarly, the systemd user session is started by `pam_systemd` and will
trigger any number of services that might consume the config files g-i-s
has created.

To ensure that files are ready before any consumers have started, chown
them right after the user credentials have been established but before
the PAM session has been started.

Helps: https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/137

This was already handled but avoids a static analyzer warning.

The remote display factory has a counter of how many remote displays
are. With that counter when there's at least one, block suspend, when
there's none unblock suspend.

This is necessary because other sessions might want to suspend without
being aware that there might be remote sessions being used. On suspend
the RDP client would disconnect and that makes the remote session die.
In the future the sessions would not die on disconnecting, but still is
undesirable the RDP client disconnecting.

- Block suspend when remote displays are active
- Support S0ix suspend when deciding if nvidia should use wayland
- Misc fixes
- Translation updates