This relies on the apparently predominant naming pattern for those files,
those of our apps not using this often do not seem to have an appropriate
file (512x512 png) to begin with.

Explicit override is also possible, by the already existing mechanism of
putting a file with the right name into the fastlane/ source directory.

Having the icon included here will allow it to be automatically synced to
the Play store.

Instead, restore their plain text fallback output that we used to have
already prior to enabling rich text support.

Contrary to the comment those exist (e.g. ul, ol), this just wasn't noticed
as due to the script-enforced formatting those always contain some spaces.

This resulted in different structures between English and translated
description texts. With this change all language variants show the same
structure.

We have to handle both entirely missing top-level elements and arbitrarily
incomplete sub-elements in the description body.

Until now we were just kept those gaps, resulting in missing titles or
incomplete descriptions. F-Droid didn't complain about that, but Google
Play does. This fixes e.g. Itinerary's metadata for de and ru.

This is likely still not complete, but with this at least most of
Itinerary's metadata translations are accepted during upload to the
Google Play store (the remaining ones are rejected for different reasons).
F-Droid seems considerably less picky about this, and works with either
form.

CMake >= 3.0 supports bracket comments, and the reStructuredText
integration code in sphinx/ext/ecm.py already supports extracting
the docs from a bracket comment instead.
Editing documentation without leading line comment markers is more simple,
e,g. when reflowing text over lines.

With ECM meanwhile requiring CMake 3.5 now it is possible to switch
(and thus follow also the approach used by cmake itself).

NO_CHANGELOG

We need this to pass the --release option for binary factory release
builds.

An alternative approach would be to set that here automatically depending
on the CMake build type. Since that however ends up producing unsigned and
thus not immediately usable APKs (or would need a whole set of extra
arguments for proper signing) I'm not sure whether that's most convenient
for local use.

This is no longer needed now that the metadata happens as part of the
build process rather than afterwards on the signing system. This allows
us to simplify the code here a bit.