Therefore we can simplify the code. The minimal interval we need
to wait to see any changes is UPDATE_FREQUENCY.

We are not reading it anymore anyway; everything is based on energy.

Having timestamps makes gbb significantly more useful for logging
because you can record and then later retrace what was happening.

https://bugzilla.gnome.org/show_bug.cgi?id=782062

We really support "energy" properly, so no need to pretend to
do for "capacity".

If the corresponding sys devices/entries are missing we should
still get 'Unknown' in the fields, but the fields should be
present.

Not only useful for humans, but also to synchronize the tests, i.e.
as an indicator when the monitor binary is started and delivering
notifications.

Currently only runs gbb info --json and checks that the simulated
battery has the right vendor and model.

We are now returning only energy values from GbbBattery, so we can
get rid of the charge related fields/functions/calculations from
everywhere that is not the GbbBattery itself.

That is, also return GbbMains, and rename it to
gbb_power_supply_discover.

Plan is to have own GbbBattery and GbbAdapter classes that can
then be used by GbbPowerMonitor and also GbbSystemInfo. New
code will be using GUdev.

That will make it easy to globally identify runs, which might come
in handy especially if we synchronize runs into a central database.

On Apple hardware the sysfs directory for the mains power supply
is called ADPx and not ACx.

https://bugzilla.gnome.org/show_bug.cgi?id=777149

Before trying to take the inhibitor lock via logind we should
check we actually have the logind connection, because we are not
failing in init() if we could not get the logind proxy.

We force stop the test runner, so the epilogue does not get played,
because it is very likely that the screen has already been locked by
gnome-shell and we would play the epilogue on the lock-screen.

This will stop the player and skip the playing of the epilogue; the
idea is to use this in emergency situations, e.g. when we are going
to sleep or really running out of battery soon.

We pre-create the logfile in order to trigger an fsync in the
g_file_set_contents call, which will do that on an atomic replace
but not for new files.

We will acquire a delay lock from logind, immediately write the
log file when we get the sleep notification, and the write it
again when we get the callback from the runner that the test has
stopped. This is also when we release the lock. Since we 'only'
acquire a delay lock, not a block lock, we might actually not
finish the test in time.

We use logind for the sleep signal, and stop the run. If the run
is in the 'running' phase we write the log to disk as well.