To manipulate the FormEngine data provider list by extensions,
it can be helpful to just set a data provider as disabled
and add an own one after the disabled one and before the
next one. This avoids funny array munging and dependency
shuffling if an extension author needs to substitute an
entire data provider with an own solution.

The concept has been implemented for node expansion
render types in a similar way and is repeated here.

..ajax routes and eID handlers that used a *pre-generated* Response
object (from the RequestHandler) now return different Content-Type
headers than before.

For backend ajax request applicaton/json was set by default,
for eID scripts no Content-Type was set (by default).

Change these controllers to use JsonResponse or a plain Response
to reflect the previous state..

The changes in this commit were intended to be squashed into the
mentioned commit – but this commit was too late. Therefore other (a bit)
unrelated optimizations to changes that patch made are included.

If a test adds some mock or prophecy revelation to the
GeneralUtility::makeInstance() stack using addInstance(),
it is important the test subject actually consumes that
instance. Otherwise, the dangling instance can have
side effects on other tests run afterwards.

The patch raises typo3/testing-framework from 3.0.0 to
3.1.0 which extends tearDown() with a test to verify the
instance stack is empty. If not, the test fails with
an accordig message.

composer command used:
composer update typo3/testing-framework

An @internal method to GeneralUtility is added to
retrieve the current instance stack, and one test
is fixed which violates this rule.

To further support the PSR-7 / PSR-15 and removal of
GeneralUtility::_GP() and friends efforts, all controllers
no longer use the second 'ResponseInterface $response'
argument given by dispatchers: Dispatchers should not
assume which type of response a controller returns, there
is no point in preparing this object.

Instead, controllers now always create one of
HtmlResponse, JsonResponse or RedirectResponse on
their own and return these objects.

Changes overview:
* Always use "new" to instantiate a response, PSR-15
middlewares allow fiddling with the object if needed,
xclassing these classes is never needed, we instead
can rely on proper API usage.
* All controller actions drop the second $response argument
and add ResponseInterface return type hint.
* Some controllers action also drop first $request argument,
but only if the action does not need access to ServerParams
at all. Those controllers that access _GP or _POST or similar
currently, keep $request for now - they have to be refactored
later anyway and then need $request.

Output Compression should be separated from the request handling, and is
now moved into a PSR-15 middleware.

This change also decouples Output Compression from Bootstrap, and the
Request Handler, so it can be re-used in other areas.

Intentionally omitted is a proper cleanup (ob_get_clean) and an explicit
write to the response object (in the middleware). That's up for later
patches. The idea of this patch is to keep functionality identical for
now.

In order to have the main request handler only deal with content creation,
and especially to move fe_user / be_user initialization out of the RequestHandler,
and to remove dependencies from Bootstrap of the RequestHandler,
TSFE is now instantiated in a PSR-15 compatible middleware.

The check if the frontend is in "maintenance mode",
set by $GLOBALS['TYPO3_CONF_VARS']['FE']['pageUnavailable_force'],
is moved into a custom PSR-15 based middleware,
effectively decoupling this logic from TSFE object.

To slowly substitute GeneralUtility::getIndpEnv() with a
better API, a new class is introduced that calculates all
normalized server parameters.
The object is added as PSR-7 request attribute in a frontend
and backend middleware.
For a transition phase, the request is made available
as $GLOBALS['TYPO3_REQUEST'] until enough core code has
been refactored to get rid of this again.

Since the session API has been adjusted it is no longer possible
to access the (now protected) sesData property of the fe_user object.
Using TSFE:fe_user|sesData|foo|bar in a TS condition will trigger
a deprecation log entry.

The two (internal) settings 'SYS/isInitialInstallationInProgress' and
'SYS/isInitialDatabaseImportDone' have been obsoleted with
the install tool rewrite in v9 and can be removed from
LocalConfiguration using the SilentConfigurationUpgradeService.

This patch provides a new "duplicate" button inside of the topbar of the
edit record form next to the close button. This button creates and opens
a new copy of the current element which is positioned right below the
existing one.
If there are unsaved changes in the currently open record, a modal
appears with options to cancel, dismiss the changes and clone or save
the changes and clone the changed record.

The frontend and backend Application and RequestHandler classes
are tightly coupled since the frontend eID request handler was
moved into a middleware and the backend ajax request handler
was merged with the regular request handler. (1:1 relationship)

There is no (longer) need to resolve the request handler in
Bootstap. For the install application we are still using two
request handlers but will dispatch them from within the
application now.

That allows us to deprecate all HTTP related code in Bootstrap (with
a separate commit) and instead implement that in an HTTP specific
ApplicationTrait.

This patch introduces a legacy RequestHandler dispatcher middleware
which ensures that registering custom request handlers using
Bootstrap::registerAdditionalRequestHandler() still works for the
frontend and backend.
(although it is marked @internal, there is interest to not just
drop this)

Can be drop-in replaced by VariableFrontend. There are no
occurrences in core code except for in tests and comments.
Configurations using this frontend can be automatically
migrated on-the-fly. Such auto-migration is not part of this
patch - this patch only touches the PHPDOC and documents
the deprecation.

The search results of the filelist access the property
`file.combinedIdentifier`. The property is not available anymore, so this
patch uses `file.identifier`, which maps to `FileFacade::identifier()`
and returns a handcrafted combined identifier.

For the default language it was possible to view the field, but on
translating the dataset, the following exception is thrown:
'PHP Warning: Invalid argument supplied for foreach() in
backend/Classes/Form/Element/SelectMultipleSideBySideElement.php line 66'

As the defaultLanguageRow keeps to be "unparsed", the $selectedItems
could be a comma separated string within the method
TYPO3\CMS\Backend\Form\Element\SelectMultipleSideBySideElement::renderReadOnly
if the TCA configuration of a field is set to 'defaultAsReadonly'.

When used with the Chrome browser, the RTE CKEditor misplaces the
position of its dropdowns/context menus (opened via right-click)
when the viewport is scrolled. CKEditor calculates the offset relative
to the <body> and assumes <body> is as long as the content and that
the scrollbar is placed on <html> (both browser defaults).
As the TYPO3 backend uses 'overflow:auto' on <body> and 'overflow: hidden'
on <html> these assumptions conflict: Once the calculated offset exceeds
the <body> height (due tue scrolling) the chrome browser scrols up.

We now move the vertical scollbar into .module-body which implicitly
fixes the CKEditor offset calculation: The calculated menu offsets are
now relative to <body> (as assumed by CKEditor) and the scroll issues
disappear as we removed the scroll bar from <body>.