metainfo: Mark app as touch-compatible and Librem5-store visible

Hi! This PR makes a few changes to the metainfo file for Calls:

Type "desktop" -> "desktop-application"

This is very much a cosmetic change, desktop is the legacy name, but we'll support that name forever. The newer name has been supported forever as well.

Mark app as touch-input compatible

This is defined in the AppStream specification and is a required block to mark applications as compatible with certain input controls. See https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-requires-recommends-control for more information. This change marks this app as explicitly compatible with touch, keyboard and pointing-device input controls.

Add custom metadata flag to indicate Librem5 store visibility

This is a flag just for us at Purism to allow our GNOME Software fork to filter out applications that specifically want to be visible on the Librem5 phone. It adds a <custom/> tag as defined in the specification: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-custom We use the custom key purism::librem5-store-visible for this, which gets propagated to the metadata collections in the software repository. Ultimately, we want to filter by input-type and screen size (and therefore have an upstreamable solution that works with any device), but until the latter is ready, using the custom key is a quicker workaround.

Validation

When validating the file with appstreamcli validate <file> I also get these info-type issues:

I: sm.puri.Calls:25: nonstandard-gnome-extension kudos
I: sm.puri.Calls:3: cid-contains-uppercase-letter sm.puri.Calls
I: sm.puri.Calls:3: cid-missing-affiliation-gnome sm.puri.Calls
I: sm.puri.Calls:10: description-first-para-too-short Calls is a simple, elegant phone dialer and call handler built using GTK+ 3.

Validation was successful: infos: 4

Addressing cid-contains-uppercase-letter and description-first-para-too-short may be worth considering, but none of these issues are critical or cause validation to fail, so they aren't addressed in this PR to keep the amount of changes low. Changing the component-id is also a big deal if the app has already been reviewed or is older, so if that was renamed it should happen early (or the info just ignored in case a change is not desired, it's a style warning).