Make translations directory configurable during install

The patch still seems to be working just fine.

Thanks @arnested and @casey for opening and reviewing this issue!

This is still a problem. I am coming from #2625820: install_check_translations() sometimes incorrectly returns NULL instead of array and found this issue now. The patch in #2 works fine, I just think we can do a bit better:

1. Instead of duplicating the logic from install_begin_request() I think it makes more sense to "store" it in the install state and just re-use it from there. Instead of just adding a third argument to install_check_translations() for this purpose I think it is better to just pass the $install_state entirely. That will also allow further fixes in the future; I am for example interested in making install_check_translations() aware of the configured translation filename pattern.
2. Creating the public files directory only makes sense if the translation directory is subdirectory of it, so we should check that.
3. We should try to add some test coverage for this.

I created a merge request that does exactly that. I added a draft change notice for the parameter change in install_check_translations() and added a basic test. I was not able to add a legacy test for the parameter deprecation because install_check_translations() performs HTTP requests, so I hit #2571475: Outbound HTTP requests fail with KernelTestBase. The only way to avoid the HTTP request is the early return that will be removed by #2625820: install_check_translations() sometimes incorrectly returns NULL instead of array so I don't think it makes much sense to exploit that here.

I am also not providing a "tests-only" patch because that triggers #3158071: Redirect loop during installation with non-English so it could possibly crash the test boot due to an infinite loop. I will comment there about my findings in regards to that.

One further note: Instead of adding yet another entry to $install_state I considered something like a general translation_config key in anticipation of further related keys, such as the filename pattern noted above. However, we already have the 'server_pattern' key which should then go under that, as well, but we currently have no way of deprecating a key there. Also it might also make sense to provide some more generic integration between $install_state and $config from settings.php, but I wouldn't want to hold this up on that. So for now I think yet another key is the least bad option.

Oh and I didn't provide an interdiff to #2 because it's almost identical to the patch itself, so it wouldn't be of much use.

Opened #3182660: [PP-1] Make translation filename pattern configurable during install for the follow-up issue regarding the filenames. I will base that one on this.

See #3182697: ComposerIntegrationTest fails under Merge request testing for the remaining test failure. This should be good for reviews, as far as I can tell.

Here's a 8.9.x patch. Not sure if this has a change of being backported, so not running the tests as of now.

This doesn't apply to 9.1.x or 9.2.x so needs to be re-rolled. The solution might need a tweak since #3181644: PCRE library version 10.35 with pcre.jit=1 makes \Drupal\Core\StringTranslation\Translator\FileTranslation::getTranslationFilesPattern() regex misbehave has landed.

We use composer patches to apply patches. Merge request patch urls are updated for every commit on the branch, which makes it a moving target. Attached is a patch containing the current state of the merge request (https://git.drupalcode.org/project/drupal/-/merge_requests/37.patch).

@alexpott there are some open threads if you could take a look.

For open threads in MR