TYPO3 Core

While introducing the new typo3/cms-composer-installers basically all resources are now in an assets folder from frontend perspective. E.g. https://brot.krue.ml/migration-typo3-composer-cms-installers-version-4/ describes thoroughly where to find them.
However I missed one scenario:

• complex favicon definitions and simple favicon retrieval per domain (Favicon here should be a summary of all relevant files, e.g. favicon.ico, browserconfig.xml, apple-touch-icon*, android-chrome* etc. ),
• as well as per-domain robots.txt

While this favicons are and should be defined in HEAD META of the site and thus already allow TYPO3 path handling, e.g. with something alike

page.meta.msapplication-config.cObject = TEXT
page.meta.msapplication-config.cObject.value = {path : EXT:mysitepackage/Resources/Public/Images/Favicon/browserconfig.xml}
page.meta.msapplication-config.cObject.insertData = 1 
page.headerData.1690530955 = IMG_RESOURCE
page.headerData.1690530955 {
    file = EXT:mysitepackage/Resources/Public/Images/Favicon/apple-touch-icon.png
    stdWrap.dataWrap = <link rel="apple-touch-icon" sizes="180x180" href="|">
  }

still in some scenarios browsers try to find some of the files without parsing a HTML document and rather expect them on the domain root, as in https://example.com/favicon.ico
While it is possible to let the httpd cover a redirect, e.g. via a symlink, in order to allow per-site favicons it would be helpful to site routes support this.

So while the old

routes:
  - route: robots.txt
    type: uri
    source: ./typo3conf/ext/mysitepackage/Resources/Public/robots.txt

won't work anymore I propose

  -route: apple-touch-icon.png
   type: path
   source: EXT:ude_template_ude2017/Resources/Public/Images/Favicon/apple-touch-icon.png

The old type URI supports files, but uses a rather complex type detection for different cases, to not interfere with that complexity, introduction an additional type path seems reasonable.

For the time being (current LTS) I wrote https://extensions.typo3.org/extension/staticpathrouteresolver
As soon as some time comes up I can probably prepare a PR