additionalAttributes for includeCSS*/includeJS* in TYPO3 core

A brief summary of development/reviews/issues/fixes for understanding why https://forge.typo3.org/issues/103882 popped up

origin

issue: https://forge.typo3.org/issues/91499
review: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65008

• mentioned in commit-message page.includeCSS* / page.includeJS* should all get page.includeCSS.custom-attribute = custom-value leading to
  <script custom-attribute="custom-value"/>
• first patchsets (starting in July 2020) had data. in all variants of includeCSS*/includeJS*
  see: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65008/1/typo3/sysext/frontend/Classes/Http/RequestHandler.php
• in patchset 17 this changed and data. was only left for includeCSS/includeJS.
  all the libs-variants uses custom-attribute=custom-value since then and got a first "cleanup"-procedure
  see: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65008/17/typo3/sysext/frontend/Classes/Http/RequestHandler.php

Oliver Hader already mentioned in https://review.typo3.org/c/Packages/TYPO3.CMS/+/65008/comment/88f22c1a_7363de08/
and https://review.typo3.org/c/Packages/TYPO3.CMS/+/65008/comment/7ed8cd5e_3dd1b619/ that data. seems to be the wrong naming as it does not only handle data.

No one involved in the review seemed to realize that data. only was used for includeJS and includesCSS but no longer for the libs-variants anymore.

Corresponding to comment https://review.typo3.org/c/Packages/TYPO3.CMS/+/65008/comment/32fd8e09_8ac6e91d/
a first bugfix raised https://review.typo3.org/c/Packages/TYPO3.CMS/+/76123 which added if. to the multiple cleanup blocks.

issue #100954

• in https://forge.typo3.org/issues/100954 the different behaviour of the include*-variants has been reported
• additionally there is a note about a regression due to another fixed attribute which stopped working with the original patch
• additionalAttributes as possible tag was mentioned first time by Ernesto Baschny
• with https://review.typo3.org/c/Packages/TYPO3.CMS/+/84206 a bugfix was merged which marked the issue as resolved
• the bugfix streamlined the multiple cleanup-blocks into a cleanup-method and resolved the mentioned regression but not the different behaviour
• at that point no one realized that the diverged behaviour still existed (at least no one documented this)

documentation issue #788

• in https://github.com/TYPO3-Documentation/TYPO3CMS-Reference-Typoscript/issues/788 it was mentioned in another place there is some inconsistency
• with https://github.com/TYPO3-Documentation/TYPO3CMS-Reference-Typoscript/pull/797 documentation was updated in some way

documentation issue #1258

• in https://github.com/TYPO3-Documentation/TYPO3CMS-Reference-Typoscript/issues/1258 the inconsistency was documented as in core#103882
• note about the inconsistency was added to documentation with https://github.com/TYPO3-Documentation/TYPO3CMS-Reference-Typoscript/pull/1259

conclusion

• This is still a bug in 12.4 LTS and main; since 12.1: includeCSS*/includeJS* do have different behaviours which is not mentioned in any changelog and only is mentioned in documentation since https://github.com/TYPO3-Documentation/TYPO3CMS-Reference-Typoscript/pull/1259
• To re-align includeCSS*/includeJS* it is necessary to add the missing parts (eiter data. or custom-attribute)
  where they are missing
• With introducing the custom-attribute-variant for some parts instead of staying with the data.-variant for all parts, which was pushed first, several problems were introduced which needed a workaround (array is duplicated and cleanup is needed)
• Whenever a new fixed attribute might get introduced to includeCSS/includeJS in future one has to update the cleanup-method as well; this needs to be known by everyone working on this part of the code
• moving to an array/subkey-variant ( data. / additionalAttributes. / define a better naming ) would make it possible to cleanup code
  • no more cleanup-method needed
  • redundancies could be dissolved
  • future refactoring would be easier
  • only defined typoscript-attributes are possible, dynamic tag-attributes are collected in subkey-array -> code is easier to read