Hardcode security coverage EOL dates for Drupal 9.4 and 9.5 (as was done for 8.8 and 8.9)

Per #3115435: Make clear why each XML update.module fixture is created the way it is, I'd love for us to be adding new update.module test fixtures with comments. E.g. see the top of core/modules/update/tests/fixtures/release-history/bbb_update_test.1_2.xml:

<?xml version="1.0" encoding="utf-8"?>
<!--
This fixture is used by Drupal\Tests\update\Functional\UpdateManagerUpdateTest.

It contains 3 releases:
- 8.x-1.0: The currently installed version in the test scenarios.
- 8.x-1.1: An available update that does not specify '<core_compatibility>'.
- 8.x-1.2: An available update that uses '<core_compatibility>' to require at
    least Drupal core version 8.1.0. Since the currently installed Drupal core
    for the tests is 8.0.0, this release will be flagged as 'Not compatible'.
-->

I know you're copy/pasting existing fixtures that don't have them, but I'd be in favor of adding them (and trying to maintain the "gate" that newly added update fixtures should always have them, as if they were docblock comments on a class).

I have trouble keeping track of our test coverage and fixtures, and I'm one of the subsystem maintainers. It's generally very hard for other folks to contribute to these issues and understand the fixtures and tests.

Otherwise, I don't think I see anything in the MR to complain about. But I'll give it a more thorough look after some belated lunch. 😉

Thanks!
-Derek

Per #2995367: Fix update module test fixture names for 8.2.0-rc2 sample data and many others, I was under the impression that our naming convention for fixtures was that the filename indicates the latest release in that fixture. I don't believe we have this convention documented anywhere, but it's mostly true. 😉 Perhaps we can add a README.md to this directory as part of #3115435: Make clear why each XML update.module fixture is created the way it is or something?

Granted, the previous fixture names touched by this issue don't match that "convention" (such as it is), but if we're renaming them, I think we should move in the direction of this standard. So what's now drupal.sec.9.9.0.xml should be renamed to drupal.sec.9.5.0.xml (since that's the latest release in that fixture after the changes in the MR).

The one being renamed to drupal.sec.10.5.0.xml is already correct (since that fixture indeed ends with a 10.5.0 release).

I haven't chatted w/ Ted about this, so I won't remove the subsystem maintainer review tag. But here's 1/2 of that review. 😉 I'll ping via Slack to see if we agree. Also temporarily assigning to @tedbow for the same.

Thanks and sorry for the confusion!
-Derek

the fixture renaming @dww suggests in #17 seems right to me

I believe these are the metadata changes Ted meant. 😉

1. @xjm's change record looks crystal clear 👍
2. @dww's feedback in #14 seems relevant and reasonable: explicit docs for rarely touched code understood by few seems wise.
3. Because this is a 9.4.0 target, I spent hours building a complete understanding of this problem space. Detailed write-up in the pre-existing thread on the merge request: https://git.drupalcode.org/project/drupal/-/merge_requests/2039/diffs#no....
4. Implemented my conclusion: https://git.drupalcode.org/project/drupal/-/merge_requests/2039/diffs?co... — hopefully @tedbow and @dww will RTBC 🤞😄
5. For the same reason, created the follow-up issue that @xjm requested in #15 and which was first raised 2.5 years ago in #2991207-120: Drupal core should inform the user of the security coverage for the site's installed minor version including final 8.x LTS releases. That will also help #3115435: Make clear why each XML update.module fixture is created the way it is. Done: #3280679: Remove legacy attributes, add supported_branches and consistently name update.module's XML fixtures

Needs Work for needing comments in XML see #14

All feedback addressed!

Looks. thanks everyone

@Wim Leers for your follow #3280679: Remove legacy attributes, add supported_branches and consistently name update.module's XML fixtures, you might to see if the scope overlaps with #3110917: [meta] Fix update XML fixtures bad data

Committed and pushed 96b87dfb70 to 10.0.x and 387143aa73 to 9.5.x and 6b59e9e50f to 9.4.x. Thanks!

Closed https://www.drupal.org/project/drupal/issues/3186927 as a duplicate of this moving over credit

Closed #3107378: Deprecate hard-coded Drupal 8 dates from update logic for the status report once this information is provided by the infrastructure as a duplicate, adding credit.