run0: run agents during setup, until pty forwarder takes over

run0: run agents during setup, until pty forwarder takes over

When services start up they might query for passwords, or issue polkit
requests. Hence it makese sense to run the password query agent and
polkit agent from systemd-run. We already ran the polkit agent, this
also ensures we run the password query agent.

There's one tweak to the story though: running the agents and the pty
forwarder concurrently is messy, since they both try to read from stdin
(one potentially, the other definitely). Hence, let's time the agents
properly: invoke them when we initialize, but stop them once the start
job for the unit we are supposed to run is complete, and only then run
the pty forwarder.

With this in place, the following series of commands starts to work
really nicely (which previously deadlocked):

    # homectl create foobar
    # run0 -u foobar

What happens in the background in run0 is this: a new session is invoked
for "foobar", which pulls in the user@.service instance for the user.
That user@.service instance will need to unlock the homedir first. Since
8af1b296cb2cec8ddbb2cb47f4194269eb6cee2b this will happen via the askpw
logic. With this commit here this prompt will now be shown by run0. Once
the password is entered the directory is unlocked and the real session
begins. Nice!

This new behaviour is conditioned behind --pty-late (distinct from the
existing --pty switches). For systemd-run we will never enable this mode
by default, for compat with command lines that use ExecStartPre=
(because we won't process the pty anymore during that command) For
run0 however this changes the default to --pty-late (unless
--no-ask-password is specified). This reflects the fact that run0 is
more of an interctive tool and unlikely to be used in more complex
service start-up situations with ExecStartPre= and suchlike.

This also merges JobDoneContext into RunContext, since it doesn't really
make sense to have two contexts around to communicate between outer
stack frame and event handlers. Let's just have one, and pass it around
to all handlers the same way. In particular as we should delay exit only
until both the unit's job is complete *and* in case of --wait the unit
is exited, one of the two should not suffice.