Draft: Prevent naming clashes when apps do install icons into hicolor

I suppose there is no such clash currently, though it makes sense to have some rudimentary protection from icons in hicolor beeing overwritten by other apps.

Most icons I found in my local /usr/share/icons/hicolor/ are already prefixed, or do just use the name of the application (e.g. chromium.png or gimp.png)

Though there is as well e.g. hicolor/48x48/status/battery-low.png which does not do so, raising the potential risk to get replaced when some other app is installed and uses the same icon-name ... I did not check yet who installs these, though I suppose it makes sense to have them prefixed.

@mak Possibly I overlook a use-case for hicolor for which prefixing makes no sense?

@ngraham Re-reading your first post of xdg-specs#132:

In practice the only way KDE is able to make icon theming work for our own apps is by adding new icons to our Breeze theme the moment an app needs them, and then hoping that any 3rd-party icon themes the user may be using will either notice this and implement the icons themselves, or else mark Breeze as a fallback theme. I believe other communities like Cinnamon, Budgie, and XFCE do something similar with their own icon themes and FDO-icon-themable apps.

I actually wonder why/if KDE apps don't just install non fd.org icons into hicolor, like it is foreseen by the spec. That is what Xfce does for its foreign icons … don't you do the same for KDE apps?

In xdg-specs#132 (comment 2409383) you suggest installing a whole icon-theme together with an (KDE)app and using that as fallback before or after hicolor. Would the installation of icons which are not available in the fd.org spec (e.g. half-full battery) into hicolor not be sufficient for your usecase?

(I did not want to further mess that already gigantic thread in the original issue)