_dbus_write_uuid_file: factor out function to write a known UUID

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=77941
Reviewed-by: Lennart Poettering
Try to read /etc/machine-id before inventing a new /var/lib/dbus/machine-id

It's least confusing if the two files have the same contents. systemd
already knows how to pick up our /var/lib/dbus/machine-id if it exists
and /etc/machine-id doesn't, but the converse is not currently true.
We should make it true, so that it doesn't matter what order
systemd-machine-id-setup and "dbus-uuidgen --ensure" were
invoked in.

In Debian, systemd currently Recommends dbus, so "dbus-uuidgen --ensure"
will *usually* - but not always! - run first, and the two files will
match. However, if you install systemd without dbus, and then install
dbus later, there will be a mismatch. With this change, it doesn't
matter which one is installed first: whichever one happens to come
first, it will generate the machine ID, and then the other one will
copy it.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=77941
Reviewed-by: Lennart Poettering
Add "Documentation=man:dbus-daemon(1)" line to systemd service

Enhances usability under systemd by making the documentation available
with systemctl status or systemctl help.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=77447
Reviewed-by: Simon McVittie
NEWS for 1.8
Avoid killing all available processes if an X error arrives early on

The timeline of events in dbus-launch's main process goes something like this:

* do initial X calls
[1]
* do some other stuff
* fork
    (child process starts doing some other stuff)
* return "intermediate parent" pid from fork()
* obtain bus daemon pid from bus_pid_to_launcher_pipe
[2]
* do things that might include X11 calls or killing the dbus-daemon

Meanwhile, the "babysitter" child goes like this:

* return 0 from fork()
[3]
* obtain bus daemon pid from parent process via bus_pid_to_babysitter_pipe
[4]
* do things that might include X11 calls or killing the bus daemon

Before [1] or [3], the right thing to do about an X error is to just
exit. The current implementation called kill(-1) first, which is
undesirable: it kills unrelated processes. With this change, we
just exit.

After [2] or [4], the right thing to do is to kill the dbus-daemon,
and that's what the existing code did.

Between [1] and [2], or between [3] and [4], there is no correct thing
that we can do immediately: we would have to wait for the end of the
"critical section", *then* kill the dbus-daemon. This has not yet been
implemented, so this patch relies for its correctness on the fact that
there are no libX11 calls between those points, so we cannot receive
an X error between them.

dbus-launch deserves more comments, or a reimplementation that is easier to
understand, but this change is certainly better than nothing.

[Commit message added, summarizing reviewers' comments -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=74698
Reviewed-by: Simon McVittie
Reviewed-by: Thiago Macieira
NEWS
Handle 0x0d0a EOLs in spawn_dbus_daemon()

On W32 dbus daemon will print output in text mode, with 0x0d0a EOLs instead
of just 0x0a. Be able to handle that.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75863
Reviewed-by: Simon McVittie
1.8.2