Add D11 Support

Key now supports D11.

We still will want to wait for a stable release of Encrypt prior to committing, however this can now proceed with working on the code against the Dev branch.

Do you need any help with testing or any remaining tasks on this?

Manual testing is always a positive, especially in any areas that may be less commonly used or that we do not have existing PHPUnit tests.

I try and give upgrades a once over, however I'm not testing every single possible combination of code execution. This will get better in time as our tests improve and as PHPStan evolves we will be able to depend upon it more.

This almost went in with the Login Block being broken (apparently we don't test that aspect) and only was caught by PHPStan (where it was hidden by other 'new' warnings unrelated to the D11 upgraded, a fault of mine for not having those cleaned up before the upgrade process started).

I believe this is close, Unless anything major occurs I currently plan to commit this in the next few days followed by a few days in the dev branch before tagging the official release.

Committed to dev to allow a few more days of testing usage before tagging a release.

@jcnventura Is there a reason you removed the core requirement in composer? This is required for composer to properly function in all use cases.

Most modules I see rely on the packager to add that

Most modules have never embraced the composer system fully. The facade was as added as a hack to allow Drupal sites to use composer without having to add a composer.json to each module Now that we have GitLab Ci comper.json is essentially mandatory and it is no longer a significant burden to maintain.

and unless something breaks it shouldn't really be added to the composer.json file

Documented https://www.drupal.org/docs/develop/using-composer/add-a-composerjson-fi... that Composer itself needs it when used to its full capability. It is necessary when using GIT composer repositories (dev branches) and also useful when using manual checkouts for merging with a parent composer.json for easier development.

having it in two places can lead to those values becoming inconsistent with each other.

I've seen that from a few modules where the maintainers didn't double check their merge requests, though I haven't seen it cause a major problem in the ecosystem.

If we don't want to maintain in two places it would be better to set the module.info file to >=10.1 instead and use the composer.json as the official support indicator. Though thank you this reminded me I needed to open #3491429: Prefer composer.json drupal/core requirement over module.info file for supported versions field for the D.O. UI problems that have stopped me from doing that on other modules.