It's like Manager.PowerOff(), which does not start poweroff.target.
Instead, the dbus methods are used for `systemctl --force exit`
or `systemctl --force poweroff`.  They shut down the system without
processing individual unit's ExecStop or TimeoutStopSec.

The comment here was misleading: the job can fail to enqueue for reasons
other than the target not existing.

The fallback caused an error to be logged, and dates back to when the
"user" directory was named "session".  units/session/exit.target was added
later the same year.

This is consistent with the documentation (man systemd), and the handling
of similar signals.  It's also consistent with `systemctl exit`, which is
what most people would expect.

The irreversible job mode is required to ensure that shutdown is not
interrupted by the activation of a unit with a conflict.

We already used the correct job mode for `ctrl-alt-del.target`.  But not
for `exit.target` (SIGINT of user manager).  The SIGRT shutdown signals
also needed fixing.

Also change SIGRTMIN+0 to isolate default.target, instead of starting
it.  The previous behaviour was documented.  However there was no reason
given for it, nor can we provide one.  The problem that isolate is too
aggressive anywhere outside of emergency.target (systemd#2607) is orthogonal.
This feature is "accessible by different means and only really a safety
net"; it is confusing for it to differ from `systemctl default` without
explanation.

`AllowIsolate=yes` is retained on poweroff.target etc. for backwards
compatibility.

`sigpwr.target` is also an obvious candidate for linking to a shutdown
target.  Unforunately it is also a possible hook for implementing some
logic like system V init did, reading `/etc/powerstatus`.  If we switched
to starting `sigpwr.target` with REPLACE_IRREVERSIBLY, attempts to run
`systemctl shutdown` from it would fail, if they had not thought to set
`DefaultDependencies=no`.  We had provided no examples for `sigpwr`, and
the whole idea is cruft to keep legacy people happy.  For the moment, I
leave `sigpwr` alone, with no risk of disrupting anyone's
previously-working, half-working, or untested setup.

Fixes systemd#6484.  See also systemd#6471