[DOCS] Fix syntax issues in changelog

There were some minor syntax issues within changelog that are now fixed.
They prevented:

* Rendering of lists
* Rendering of code blocks
* Rendering of inline code

Resolves: #89825
Releases: master
Change-Id: Ic272e989e7841eac8c6f04f4819354b0926cd6df
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62510
Reviewed-by: Oliver Bartsch <bo@cedev.de>
Reviewed-by: Susanne Moog <look@susi.dev>
Reviewed-by: Jan Stockfisch <typo3@jan-stockfisch.de>
Reviewed-by: Daniel Goerz <daniel.goerz@posteo.de>
Tested-by: Susanne Moog <look@susi.dev>
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Daniel Goerz <daniel.goerz@posteo.de>

typo3/sysext/core/Documentation/Changelog/master/Deprecation-89468-DeprecateInjectionOfEnvironmentServiceInWebRequest.rst

@@ -26,7 +26,7 @@ Affected Installations
 ======================
 
 All installations that implement subclasses of :php:`\TYPO3\CMS\Extbase\Mvc\Web\Response` and expect an instance of the
-:php:`EnvironmentService`to be injected into :php:`\TYPO3\CMS\Extbase\Mvc\Web\Response::$environmentService`.
+:php:`EnvironmentService` to be injected into :php:`\TYPO3\CMS\Extbase\Mvc\Web\Response::$environmentService`.
 
 
 Migration

typo3/sysext/core/Documentation/Changelog/master/Feature-89718-UnifiedPHPAPIForLoadingPageTSconfig.rst

@@ -16,12 +16,12 @@ TYPO3 Backend, which can also be used to define Backend Layouts.
 
 In order to streamline this functionality, the loading process of
 gathering all data from a rootline of a page is now simplified in
-a new PageTsLoader PHP class.
+a new :php:`PageTsLoader` PHP class.
 
 Additionally, parsing, and additional matching against conditions,
 which was added later-on in 2009 and put on top, is now separated
 properly, building a truly separation of concerns for compiling
-and parsing TSconfig. This is put in the PageTsConfigParser PHP class.
+and parsing TSconfig. This is put in the :php:`PageTsConfigParser` PHP class.
 
 
 Impact
@@ -30,19 +30,18 @@ Impact
 When there is the necessity for fetching and loading PageTSconfig,
 it is recommended for extension developers to make use of both new
 PHP classes:
+
 - :php:`TYPO3\CMS\Core\Configuration\Loader\PageTsConfigLoader`
 - :php:`TYPO3\CMS\Core\Configuration\Parser\PageTsConfigParser`
 
-Usages for fetching all available PageTS in one large string (not parsed yet):
+Usages for fetching all available PageTS in one large string (not parsed yet)::
 
-:php:
     $loader = GeneralUtility::makeInstance(PageTsConfigLoader::class);
     $tsConfigString = $loader->load($rootLine);
 
 
-The string can then be put in proper TSconfig array syntax:
+The string can then be put in proper TSconfig array syntax::
 
-:php:
             $parser = GeneralUtility::makeInstance(
                 PageTsConfigParser::class,
                 $typoScriptParser,
@@ -56,4 +55,4 @@ The string can then be put in proper TSconfig array syntax:
 Extension developers should rely on this syntax rather than
 on :php:`$GLOBALS['TSFE']->getPagesTSconfig()` or :php:`BackendUtility::getPagesTsConfig()`.
 
-.. index:: PHP-API, TSConfig, ext:core
+.. index:: PHP-API, TSConfig, ext:core

typo3/sysext/core/Documentation/Changelog/master/Important-88655-ChangedLoadingOrderOfRTEConfiguration.rst

@@ -12,28 +12,33 @@ Description
 The order in which RTE Configuration is loaded has been changed.
 
 The new order is:
-1. preset defined for a specific field via PageTS
-2. richtextConfiguration defined for a specific field via TCA
-3. general preset defined via PageTS
-4. default
 
-This results in a change if you were used to using `RTE.default.preset` to overwrite _all_ RTE 
-configuration presets - as those with specific configuration in TCA now use their specific settings 
+#. preset defined for a specific field via PageTS
+
+#. richtextConfiguration defined for a specific field via TCA
+
+#. general preset defined via PageTS
+
+#. default
+
+This results in a change if you were used to using :ts:`RTE.default.preset` to overwrite _all_ RTE
+configuration presets - as those with specific configuration in TCA now use their specific settings
 instead of falling back to the default. Please make sure, that this new behavior is fitting for your
 use cases.
 
 If you are an extension author and you want your RTE fields to use the systems default configuration
 (the one configured for the complete web site) please do not set a specific preset for your fields.
-If you as an extension author want to provide a specific preset - for example because you are 
+If you as an extension author want to provide a specific preset - for example because you are
 providing a custom parseFunc - set the property `richtextConfiguration` in TCA.
 
-If an extension provides a custom preset for a specific field and you as an integrator want to 
+If an extension provides a custom preset for a specific field and you as an integrator want to
 override that configuration (for example to use "your" default), set it specifically for that field
 in TSConfig or overwrite the TCA configuration.
 
 For example:
-If the blog extension configures `'richtextConfiguration' => 'blog'` for the tag description and 
-you want the tag description to use the default preset, set 
-`RTE.config.tx_blog_domain_model_tag.content.types.text.preset = default`.
 
-.. index:: RTE, TCA, TSConfig, ext:core
+If the blog extension configures `'richtextConfiguration' => 'blog'` for the tag description and
+you want the tag description to use the default preset, set
+:ts:`RTE.config.tx_blog_domain_model_tag.content.types.text.preset = default`.
+
+.. index:: RTE, TCA, TSConfig, ext:core

typo3/sysext/core/Documentation/Changelog/master/Important-89645-RemovedSystemLogOptions.rst

@@ -14,7 +14,9 @@ options have been kept in TYPO3 v9 for backwards-compatibility of existing exten
 anymore.
 
 The affected options are:
+
 - :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['systemLog']`
+
 - :php:`$GLOBALS['TYPO3_CONF_VARS']['SYS']['systemLogLevel']`
 
 Impact