This change is preparatory refactoring in order to support
native JavaScript modules (ESM) where a module can't be used both
as classic script-src and as ES6 module providing exports at the same
time (this was/is possible for AMD as implemented in #95953):
`export` is an invalid keyword in non-module scripts and cannot be
specified conditionally, that is very different to AMD modules where
`define()` can be called conditionally.

JavaScriptHandler currently has three execution modes:

 * If used as script-scr: Call processItems from text content for:
   * RequireJS configuration
   * Generic JavaScriptItems processing
 * If used as AMD module:
   * Generic JavaScriptItems processing

JavaScriptHandler is now separated into the following three concerns:

JavaScriptItemProcessor
-----------------------
The previous processor "mode" is now available as
streamlined JavaScriptItemProcessor module, in order
to drop type invariance (it requires parsed objects
instead of allowing raw json data or objects)

JavaScriptItemHandler
---------------------
The previous JavaScriptHandler module that processes
text content and calls arbitrary hooks has been
simplified to the one usecase that was actually being used:
Handling JavaScriptItems by parsing the text content.
The extracted JavaScriptItemProcessor is used as backend
for the actual work.

RequireJSConfigHandler
----------------------
The RequireJS configurator is now available as
separate module, as this logic is only needed once and not by
other modules. There is no need to keep that functionality in
JavaScriptItemProcessor, especially as it has been hidden from
AMD modules, which complicated the JavaScriptHandler.
This extraction also actually allows to make use of modules
in JavaScriptHandler and therefore enables the possibility to
share code using JavaScriptItemProcessor.

Also the code has been migrated to TypeScript.
JavaScriptItemHandler and RequireJSConfigHandler do not export
or import code, therefore they are usable as plain targets
for script-tags.

In addition the JavaScriptItemHandler is now executed
asynchronously, which allows the browser to parse DOM
in parallel. (synchronous mode is required for RequireJS
config, but not for loading of requirejs-modules/instructions,
they are asynchronous anyway).

FileClipboardCest is adapted to wait more than 1 second, since the
rerendering of the clipboard (a new iframe request is made) takes
longer than 1 second in some test runs (not locally, but on CI)
(note: the default 1 second wait timeout is configured in
typo3/sysext/core/Tests/Acceptance/Application.suite.yml, but that's
too less in this case).

Releases: main
Resolves: #96476
Related: #95953
Related: #96323
Change-Id: I48a5751cea03537344e925beba365841e0855dde
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72892


Tested-by: core-ci <typo3@b13.com>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Tested-by: Benni Mack <benni@typo3.org>
Tested-by: Benjamin Franzke <bfr@qbus.de>
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
Reviewed-by: Benjamin Franzke <bfr@qbus.de>