Extension configuration is now stored as plain array
instead of serialized values. To ensure backwards-
compatibility and stream-line core usage, the old
values will still be stored and written in
$GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf'] whereas
the new array will be stored in
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF'].

As a second step we are going to introduce an API for
retrieving extension configuration to remove the necessity
for GLOBALS access in this case.

Currently calling the install tool modules from within the Backend does a
simple redirect with adding GET variables.

That's the reason why you need to re-authenticate again, and the context
is handed over as a query parameter, which is simply not needed at all.

Now, the redirect is removed, as the Backend entrypoint / request handler
handles the authentication of the backend user, and the standalone entry
point deals with the install tool password etc.

The context parameter is now detected by the entry point (!) as well,
allowing to get rid of quite some code.

There are some more consequences:
- Calling the install tool from the backend does not validate if you configuration
is set up (= recovery necessary) -> since you're already in the backend we guess
you're fine anyway.
- Redirect functionality is almost not needed anymore in the regular request handler
- routeParameters concept was removed again (which was introduced a couple of weeks ago)

Additionally, the contextService could be replaced at a later stage with just
a string.

* Show messages within page module and form engine if the backend user
does not have access to the selected form definition.
* Show flash messages within page module and form engine if the
ext:form configuration is invalid.

Defining all configuration options in TYPO3 Install Tool is now handled
via a Yaml file which additionally specifies the "type" of the configuration
option, allowing to use further render settings, one of them already introduced
for "allowedValues". This moves the "All Configuration" to a more flexible output
rendering of dropdowns for a specific type.

This patch removes the previously introduced runtime cache
and early returns from TemplatePaths, both of which were
implemented in an attempt to prevent excessive TypoScript
parsing - an issue which has since been solved by optimising
the TypoScript parsing enough that a cache and early return
is no longer necessary (no longer constitutes a significant
performance increase).

The early return and caching introduced regressions described
in the related forge issues. Removing both solves those problems.

In addition, the method resolving TypoScript paths is now
covered by extensive unit tests confirming everything from
merging to sorting of template paths. An average of 8 tests
cover the method's lines. Each of the expected behaviors
is now declared as specific test.

* GeneralUtility::removeDotsFromTS() is called on a far
smaller array instead of all TypoScript.
* Fallback paths are allowed to be cached in the runtime
cache which avoids re-reading TypoScript when no
paths are configured in TS.

Saves several thousand calls to removeDotsFromTs
which in turn saves several tens of thousands of calls
to in_array.

A new option $GLOBALS['TYPO3_CONF_VARS']['SYS']['systemMaintainers']
is introduced, which contains a list of Backend User uids. It is
then possible to restrict access to backend modules to system
maintainers - most importantly the four Install Tool modules.

When this option is not set in LocalConfiguration.php, then all
admins are system maintainers, same goes for accessing TYPO3
in Development context.

This is the first step to remove the necessary "enter your
intall tool password" when accessing the install tool from
within TYPO3 Backend.

The install tool brought its own "status message" class
structure since the 6.2 refactoring. This is used at many
places in the install tool for message handling.

The core has a very similar class construct "Messaging"
with only little dependencies, too. To simplify a later
separation of 'install tool' and 'installer' the internal
status message class structure is removed and transitioned
to the core Messaging structure. to get rid of just
another special thing the install tool does.

The ext:core FlashMessage and FlashMessageQueue now both
implement the \JsonSerialize interface. This allows direct
json_encode() calls on these objects, helpful for instance
for ajax responses.

In ext:install "Environment checks" suhosin specific checks
have been removed since the project is dead and only has a
pre-alpha php 7.0 fork, so probably nobody is using
that with the given core PHP constraints anymore.

The left-over signals in EXT:install/ext_localconf.php belong
to EXT:core (uses classes from EXT:core anyways) and since
both extensions are required at any time (part of minimal system)
this is just a separation cleanup.

In order to get the controllers free of security checks, the logic of
authentication/session handling is moved from various controllers into
the RequestHandler and the Application.

Additionally, a second RequestHandler (RecoveryRequestHandler) is introduced
which acts as a fallback if TYPO3 is not installed yet, or the installation is
broken (e.g. missing PackageStates.php).

This brings a cleaner dispatching mechanism, having the RecoveryRequestHandler
(which can handle any request) dealing with the StepController, and the
regular RequestHandler (with higher priority) for handling the maintenance
functionality for running installations.

The trigger values can be hardcoded here, as the previous
filtering only gives us fields for which we want to hide
the explanation and show the input field.
Previuosly each time a new link field was created (as an
IRRE element for example) the input and explanation fields
were triggered. This created confusion with editors and
also broke the trigger button, so that fields that were in
the explanation mode could not be triggered back to input mode.

Fix "Find imagemagick / graphicsmagic in specific direcory" input
field in image preset handling.
The preset handling is still a bit ugly and does not integrate
too well into the ajax based handling all other cards use. This
needs a bigger refactoring and is not done with this patch.
For now, submitting a path to the image preset path input field
reloads the view and executes the path test, so the functionality
is there, it's just a bit ugly to use.

The install tool (/typo3/install.php) is at the same directory location
as the backend interface. The links are fixed to point to the correct
locations.
Remove an obsolete f:if along the way, this partial is only loaded
in non backend context anyway.

Before refactoring of the install tool with #76084, a
'fatal error handler' was in place to redirect to the
extension checker if a fatal php error was detected
during one of the main "tool" actions.
Now, the main controllers of the install tool never
load non-core extension data anymore, those can't
fail due to issues with specific ext_localconf.php or
ext_tables.php files. This extension loading now happens
only in ajax actions and thus can't kill the whole install
tool anymore.
Left over error handler code is removed from the
ToolController with this patch.

With the doctrine migration a signal formerly located in class
SqlExpectedSchemaService has been moved to class SqlReader.
The old SqlExpectedSchemaService has been removed with issue #82148.
Slot for that moved signal should now switch to the string
literal of the class name.

Since Doctrine DBAL has been integrated into the TYPO3 core during
version 8 development and Extbase queries have been adjusted with
TYPO3 version 8.4.0, the behavior on distinct query results were
mixed up as well.

Extbase queries using the query-builder until TYPO3 7 LTS contained a
dedicated `SELECT DISTINCT` when retrieving data which lead to unique
entities, especially when implicit `LEFT JOIN` statements have been
added to the query to resolve cardinalities of the types one-to-many
and many-to-many.

Besides that using `GROUP BY` is not reliable in this particular
Extbase scenario. Further details can be found in MySQL documentation:
https://dev.mysql.com/doc/refman/5.7/en/group-by-handling.html

If im / gm are not configured, the Environment module may
throw a fatal since refactoring. The patch sanitizes that
and fixes the "Current configuration" view in
"Image Processing" card which broke during refactoring, too.

Some install tool cards load content on opening the card.
The patch now fires events on open and modules single card
JS binds to those events to load content.
This fixes the prev/next buttons in docheader to init
card content correctly.

To completely disable the Install Tool you can just leave the
`installToolPassword` value empty in your LocalConfiguration.
Problem here is that not all password hashing methods can handle an
empty value without giving PHP warnings.

This patch changes the password check in reporting to skip the install
password hashing/check when there is no password.

The em in "Installed Extensions" has a button "Download SQL Dump"
for all extensions that provide ext_tables.sql. On click, an sql
dump file is sent.

This feature is severely flawed:
* Dumps of extensions that add fields to existing tables contain
a 'drop table' of these tables, the 'import into' statements are
broken and only (try to) add these fields again. This easily
leads to hazard in DB if importing such a dump.
* There are no charset specs and other meta data whatsoever in the dump.
* The dump is not dbal compatible, field definitions and imports
are incomplete.

We assume nobody really used this feature in a sane way, even at
this prominent position in em. The lack of bug reports to this
broken feature and the fact there have been zero changes in this
area since main em refactoring years ago support this view.

There are way better options to retrieve proper data specifications:
* The list module has a csv export
* Ext:impexp supports export and import in a much better way
including proper relation handling and other options.
* Low level db exports and backups should be done on cli or
with more powerful guis like phpmyadmin or other db engine
specific tools.

The feature is dropped without substitution.

The v8 backport of this patch will just remove the button from
the em list view, but keep all code.

travis-ci still chockes on executing the functional tests
which take ages, even with various tricks in place.
The patch reduces the travis execution to unit tests
only since all main tests are executed via our bamboo
environment anyway beforehand.

travis-ci still chockes on functional tests, even if
splitting them among lots of single tasks. Run less
tests in parallel and split to ever more jobs to have
a higher chance for 10 minute output with given cpu
constraints.

In various places throughout the core we are using timestamps followed
by a dot as unique identifiers for array keys (for example the avatar
service is registered that way). The ArrayUtility renumbering function
renumbers these keys on writing configuration, meaning that you cannot
overwrite services registered like that via the configuration manager.

ArrayUtility should not re-order strings containing a number ending with
a single dot.

Refactor the 'clear tables' view of the install tool:
* Main content is loaded on opening the card via ajax
* Tables with 0 rows are no longer shown
* Refresh view after 'clear this table' ajax action has been clicked

The patch applies a major refactoring of the "tool" part of the
install tool. As the most visible change, the install tool
application is now split from the "install" backend module menu
entry into four different entries - "Maintenance", "Settings",
"Upgrade" and "Environment". This is in-line with the strategy outline at
https://decisions.typo3.org/t/typo3-system-management-the-big-picture

The patch can be seen as the main separation and split patch to
introduce the integration of the install tool application
into the overall backend look and feel.

On the visible side, single install tool actions that were
spread over the old menu entries like "all configuration" and
friends are now given single "cards" within one of the four
main module entries. The "standalone" version of the install
tool is now similar to the backend view - just without all the
other module menu entries.

Aside from this major visible change, the patch comes with
a main refactoring of the underlying PHP code and click behavior:

* All "action" buttons that initiate something are now ajax based.
Codewise, this is the major part.
* No main controller loads ext_tables / ext_localconf anymore.
* Main "Install.js" is now mostly a dispatcher to load specific
requireJs components determined by given clicked main module.
* Major refactorinng of JavaScript output and click-flow.
* Introduce various new "services". Ajax actions always return
objects and arrays, but no HTML. This is a major step towards
proper cli and psr-7 integration.

Even with the install tool paradigm "never cache anything", the
application feels very snappy due to slim main controllers
and straight single Ajax action triggers.

Some parts of the internal PHP API of the install tool have been
changed. While the install tool is "internal" anyway, this patch
has been marked as [!!!] to hint extension developers in the
unlikely case it breaks some low level extension.

The state of this major change is not "perfect": There are
various details to improve. However, this patch has more than
9k lines, all major parts work fine and the huge file juggling
prevents other patches from being integrated. Glitches and
further improvements can be done with small patches afterwards.