Add based API for (fix #548) (for Autopage and other future applicaations)

[geeksville]

Summary of changes/motivation

The main component of this change is adding api.py, a dasbus based dbus API server with the following features:

• icon pack enumeration
• page enumeration
• addpage(name, json)
• removepage
• streamdeck enumeration
• export the datadir location (for eventual use adding other metadata/backgrounds on-the-fly)

To support this feature a small number of changes were needed elsewhere:

• Change add_page so it can throw if the page already exists (the threeish usages elsewhere in the app now have a try/catch to handle that)
• The flatpak yaml had to be updated to add dasbus (and since the tool is now newer it emitted slightly different yaml)

How to use

This new api can be used either via the autopage application or the "stream-client" test harness/client. Run "pipx install stream-autopage" to get the current version of these tools.

Here's a video of an app using the api (with streamcontroller automatically changing pages when apps change)

Questions for devs

A few questions before I think this change should be merged:

• I think the autopage idea is pretty slick and shareable way to automatically add pages for detected running apps. Please check out my README for more info. That said I tried to structure this (small) api so that it could eventually support other apps.
• I used dasbus because it is much newer than dbus-python (and no painful hand xml generation - it is mostly python attribute driven), the API is essentially a superset of dbus-python. Elsewhere in your project you are using dbus-python. Are you okay with both being in the app. I think it is basically 'fine' but if you prefer I can amend this PR to use dbus-python (not my preference) or change your existing usages to use dasbus and remove dbus-python (my preference). Your thoughts?
• This API is dbus based and I saw notes in the code with (early?) macos support. dbus doesn't work there. If macos is a requirement I could change this api to use some other message passing api (rabbitmq? zeromq? instead). I'm not a huge fan of exposing this sort of 'user local stuff' via http though. Thoughts?
• While making this change I noted a lot of 'dev time' dependencies are being included in the flatpak, I bet it could be made a lot smaller by doing a two stage build and not including those. If you want me to look into this let me know.
• I've tried to structure the autopage app so that when it is a bit more mature we could just move it into the Streamcontroller flatpak (if ya'll want that).

Rock on, thanks for making this. I'm happy to discuss this idea more either here or in #548