With the new site handling, the overlayType for fetching
records in the frontend context is always set to
OVERLAYS_ON_WITH_FLOATING, which resolves to
the previous TypoScript settings:
- config.sys_language_overlay = 1
- styles.content.get.select.includeRecordsWithoutDefaultTranslation = 1

However, the place where "includeRecordsWithoutDefaultTranslation"
is evaluated does not check for the actual
Language Aspect of the Context API, which makes
it impossible to fetch records without "l10n_parent"
= (free mode), except for setting this option
explicitly on each TypoScript "select." query.

The patch moves the functionality into a separate method,
which allows to better unit test all options.

When using workspaces and the record properties
should be shown, the wrong field (_ORIG_pid instead of
t3ver_oid) is used. This is introduced by
a cleanup patch of mine 1y ago, where an accidental
null coalescense evaluation is used.

Adds a new method HttpUtility::buildQueryString() using
http_build_query() instead of reimplementing the encoding-process like
the old method GeneralUtility::implodeArrayForUrl() did.

As the parameter $rawurlencodeParamName of implodeArrayForUrl() was set
to "false" by default and used in several places without manually
setting it to "true" using that method could lead to potentially unsafe
non-encoded parameter names.

Some unit-tests had wrong URLs with non-encoded braces [...], which were
adapted to be properly escaped as well.

Acceptance tests of testing-framework have been refactored
a bit to be easier usable by extensions. Core needs some
adaptions to cope with that. styleguide has been
slightly improved and is raised along the way.

[BUGFIX] Set constraints in `FrontendRestrictionContainer` depending on workspace context

The `FrontendRestrictionContainer` must not respect the hidden flag, if
the request happens in a workspace context. The reason is that for
example pages that are created in a workspace have a hidden LIVE version,
which makes overlaying impossible.

This patch changes the behavior to act the same as
`PageRepository::enableFields()` does.

Applying a strict "string" type to values that are "null" will
lead to type errors for TCA properties that are not configured
- most probably for "languageField", "transOrigPointerField"
or "translationSource".

With the increased number of functional tests in v9 we
should squeeze out as much performance as possible from
the tests so waiting for bamboo is not so annoying. Not
loading xdebug gives us roughly 10-30% for functionals.

Extend the "Lint scss ts" bamboo job to also build css
next to js and only after that verify with git status
no file changed. This should prevent outdated css as
recently fixed with #86789.
Additionally switch from npm to direct grunt calls,
to be in sync with runTests.sh and to allow kicking
npm from the docker images entirely.

SlugHelper fetches records of the same language, and takes the
pageId of the _current_ language record (uid), which is wrong.
For records, it must be 'pid', for pages it must be 'uid', but for
translated pages it must be 'pages.l10n_parent'.

When a new storage object for the "local" driver is being created
it is not possible to retrieve the new object instantaneous. The
objects are being cached in a local static variable which needs
to get flushed (set to "null") first.

When a mount point, that is overlayed, redirects to the overlaying page,
don't throw away existing mount point parameters. The other mount point
parameters may specify a mount point upwards in the root line.

Under normal circumstances the page should not be linked at all. However
a redirect is provided and as it is provided it should work as expected.

Using (valid) unicode characters in
GeneralUtility::verifyFilenameAgainstDenyPattern was not possible due
to a missing unicode modifier when evaluating regular expressions.
The unicode modifier has been added.
Since unicode errors in regular expressions will lead to `false`
results, it is important to perform type-safe checks against `0`.

The form setup properties within "additionalViewModelModules" must be
written as numerical associative arrays to make it possible that
multiple extensions can extend the form editor with javascript modules.

According to the documentation there is no limit of the used
additional parameters. However during parameter processing, there
is a limit of 4 parameters applied. This limit needs to be unset
when dealing with a USER display condition.

The TYPO3 backend is eager to generate the same URL
with the same parameters multiple times, causing a lot
of cascading calls to URI parsing, token generation etc.

Turning the UriBuilder into a Singleton removes many
hundreds of calls to instantiate the object - and remembering
the URLs that were generated further saves many hundred
calls to UriBuilder->buildUri in for example the page module.

Use pageType-parameter from f:uri.page instead of providing
the type through additionalParams.
And don't include the page-parameter unless we are on another page
than the first one (page=0). Many DataProviders might only use one
page anyway.

The list of old hashes by cleaning up the reference index can
be very long. To avoid exceeding query limits like maximum number
of placeholder per query or the max allowed statement length these
large lists are split into chunks of safe length before processing.

If somebody has no RTE extension available, there is also no
RTE processing information available, so the default
from RteHtmlParser is used. However, tags like <abbr>
are then not provided by the yaml configuration, so they are
not allowed, and thus - escaped.

The SlugHelper now receives an encapsulated RecordState object that
represents a record.

This allows fine-grained control over a record and helps resolving
related information, which is required to resolve slugs properly in a
case where e.g. the node ("parent") and language uid can occur multiple
times.

The RecordState contains:

- an EntityContext which describes a variant of a record by its language
and workspace assignment

- a node object (EntityPointer) that points to the node (aka "parent") of
the record

- a EntityUidPointer that describes the origin of the record by its table
name and uid

The RecordStateFactory creates such RecordState objects and enriches them
with links (EntityPointerLink) that point to languages and versions, that
are also represented by EntityPointer implementations.