Add desktop and metadata files

[samtygier]

To submit to Flathub there are a few requirements https://github.com/flathub/flathub/wiki/App-Requirements

This adds a .desktop and appstream .metadata files. It also installs these to the expected locations. This will also cause b-em to be added to the linux application menus when installed normally.

There are a few choice that might need reviewing.

1. The ID, I used uk.org.stardot.b-em , the b-em website in reverse DNS notation. an alternative would be io.github.stardot.b-em . See https://docs.flatpak.org/en/latest/conventions.html#application-ids
2. File location. I just put these in the top directory, they could also go in a /data directory
3. All the descriptions
4. Categories, There are few possible options, see https://specifications.freedesktop.org/menu-spec/menu-spec-1.0.html#category-registry

There are few other things needed to be included on flathub:

A tagged release. Flathub needs to build from a release tag https://github.com/flathub/flathub/wiki/App-Requirements#stable-releases-reproducible-builds

Sandbox permissions. Ideally flatpak packages are sandboxed with limited access to the filesystem. I think most users would want read and write access to disks stored in their home folder. But this could be restricted to only the document folder. This would be specified in the flatpak yaml file that gets put in the flatpak repository.

[SteveFosdick]

This looks good to me so far. For the ID there is nothing at b-em.stardot.org.uk but I assume that doesn't matter - it is being used a different namespace where its purpose is to distinuish applications in a way that leaves plenty of room for expansion.

That list of top level categories is a bit hard - choosing system is probbably about the best.

As for extra files, if there is a whole bunch of stuff specific to flatpak then a directory for them would be good as it would give someone who knows nothing about flatpak an idea what they are for. It isn't worth it for one single file and a .desktop entry and associated icon would presumably be useful it were packaged in some other way, e.g. in the native package format for a Linux distro.

I think the big sticking point is a release. I think it would be misrepesenting things to call what we have in GitHub release 2.,2. That was the last release made by Sarah quite some time ago and there has been quite a bit of change since - the move to Allegro 5, more tube processors, more bug fixes etc. So we should probably release what we have - maybe call it 3.0. I am sure later that day or the day after someone will find a bug but at least we have a tag and can say we've followed the flatpak requirements.