fprintd: Use GDBus and support async Polkit requests

Fprintd is dependent on the deprecated dbus-glib, also this doesn't provide various features we can take advantage of, like the ones for async authentication mechanism.

So, remove all the dbus-glib dependencies and simplify the code.

In the initial commit there's no further refactor (unless style fixes when a block was going to be modified anyways), and keep everything as it used to work, while adding further improvements in subsequent commits.

Internally, we just use dbus-codegen to generate the skeletons, and we use the generated FprintdDBusManager with composition, while we implement the device skeleton interface in FprintDevice, so that we don't have to use it as a proxy, and keep being closer to what it used to be with dbus-glib.

Then I've added various refactor commits.

In the second part of the MR, I've addressed the main security issue we left open (#5 (closed)), and GDBus generated interface skeletons support natively an authorization method that allows to filter calls before we get into the method callback and that gets called into the call thread, before we go back to main thread.

As per this, we can move all the polkit and other authorization checks into this callback so that method handlers are now just assuming they're the right to perform the requested operation.

As per the fact we'll share some data between another thread and the callbacks, we will need to introduce some locking mechanism to ensure safe data access.

This might be reduced by moving the claiming checks back to the method, but would lead errors to be handled in different ordering, and so the user to be requested for a password, and then - in case fail. This can still happen now, but only if there are concurrent requests.

Added few more tests, even though the majority of the code-paths were already covered by tests.

I also wanted to cover #4, but unfortunately the introspection XML files would require a major refactor to be ported to gtk-doc, so I didn't want to mix those. Even because API could probably be updated at all.

Fixes: #61 (closed), #5 (closed)