core: add support for a configurable system-wide start-up timeout

When this system-wide start-up timeout is hit we execute one of the
failure actions already implemented for services that fail.

This should not only be useful on embedded devices, but also on laptops
which have the power-button reachable when the lid is closed. This
devices, when in a backpack might get powered on by accident due to the
easily reachable power button. We want to make sure that the system
turns itself off if it starts up due this after a while.

When the system manages to fully start-up logind will suspend the
machine by default if the lid is closed. However, in some cases we don't
even get as far as logind, and the boot hangs much earlier, for example
because we ask for a LUKS password that nobody ever enters.

Yeah, this is a real-life problem on my Yoga 13, which has one of those
easily accessible power buttons, even if the device is closed.
core: print 'startup finished' messages even if we log to console
resolved: fix typo in log message
core: introduce "poweroff" as new failure action types

Also, change the default action on a system start-up timeout to powering off.
core: split up "starting" manager state into "initializing" and "starting"

We'll stay in "initializing" until basic.target has reached, at which
point we will enter "starting".

This is preparation so that we can change the startip timeout to only
apply to the first phase of startup, not the full procedure.
update TODO
bus: factor out bus policy items

In order to re-use the policy definitions, factor them out into their own
files.
bus: add kdbus endpoint types

Add types to describe endpoints and associated policy entries,
and add a Endpoint instace to ExecContext.
bus: add core to create custom endpoints

Custom endpoints are alternative connection points to a bus, allowing
specific policy to be uploaded.
bus: parse BusRestrict in service files

Add a new field called BusRestrict to define custom endpoint policies. If
one such directive is given, an endpoint object in the service's ExecContext is
created.
namespace: add support for custom kdbus endpoint

If a path to a previously created custom kdbus endpoint is passed in,
bind-mount a new devtmpfs that contains a 'bus' node, which in turn in
bind-mounted with the custom endpoint. This tmpfs then mounted over the
kdbus subtree that refers to the current bus.

This way, we can fake the bus node in order to lock down services with
kdbus' custom endpoint policy logic.
service: hook up custom endpoint logic

If BusRestrict= was passed, the parser function will have created
an ExecContext->endpoint object, along with policy information.

In that case, create a kdbus endpoint, and pass its path name to the
namespace logic, to it will be mounted over the actual 'bus' node.