[PP-1] Make translation filename pattern configurable during install

Created a merge request now based on #2950407: Make translations directory configurable during install.

The part to review for this issue is this commit: https://git.drupalcode.org/project/drupal/-/merge_requests/47/diffs?comm...

Some notes:

1. We are touching the only place that install_retrieve_file() is called from taking a directory to a filename (which it already supports), which is why I went ahead and deprecated the directory-associated logic. This could be done in a follow-up but seems related enough to me. I did not, though, create a draft change notice yet, so the link in the code is bogus for now.
2. _install_prepare_import() is a very strange function which probably makes the change there difficult to understand, as well. I will try to explain: The removed regular expression attempts to figure out the version from the filename. However, just above the hunk shown in the diff is this line:
   

           $files = locale_translate_get_interface_translation_files(['drupal'], [$langcode]);
     

   locale_translate_get_interface_translation_files() calls out to locale_translate_file_attach_properties() which already figures out the version from the filename. So the current regular expression is completely unnecessary and we can instead just use the already determined version. So since we have to touch that code anyway to do the fallback if the version is not part of the filename I opted to do this tiny amount of clean-up to remove the regular expression. It could also be avoided theoretically, though. Note also that there are a bunch of other things that could be cleaned up here, which I did not attempt in order to keep this in scope. in particular locale_translate_get_interface_translation_files() does not fully support configurable filename patterns, it just has a fairly loose regular expression so that a bunch of patterns - including the one from the issue summary - is supported. Fixing that to properly support all filename patterns is not within the scope of this issue in my opinion.

3. The change to FileTranslation could and should be tested by a dedicated kernel test. That is not done as of now.

Here's a patch for 8.9.x on top of #2950407-14: Make translations directory configurable during install.

Fixed the tests so this will hopefully be green. The "to-review" part for this issue can be seen here: https://git.drupalcode.org/issue/drupal-3182660/-/compare/5838f78c5d5a65...

Not uploading a new 8.9.x patch because the changes are cosmetic only. The test fails before just trigger the newly introduced deprecation, they don't expose any breakage.

The tests that triggered those deprecations show that we do actually have some test coverage of the FileTranslation class, which I was not aware before. (I had just blindly searched for a test class called "FileTranslationTest"...). So on top of just fixing the deprecation notice, I expanded the two tests to cover the functionality added here, so this should cover the need for additional test coverage mentioned in #3.3

Note that InstallTranslationFilePatternTest is somewhat of a strange test in that it's a kernel test, but it "unit tests" the FileTranslation::getTranslationFilesPattern() method via setting it to public via reflection. The reason it needs to be a kernel test in its current form is that it uses the file system service from the container. So it would be better to mock that service and turn the test into a kernelunit test. However, it could also be argued that it basically provides duplicate test coverage of InstallerTranslationFilenameTest so maybe it can also just be removed, in particular because there are people (including me) who are not very fond of testing protected methods via reflection. So for now just leaving as is (with the expanded coverage) as (hopefully) the least controversial change, but absolutely open to either removing it or turning it into a unit test.