Adjust project_browser to the class renaming changes in package_manager

Since this is a hard BC break, but not in Project Browser itself, here's the release strategy I propose:

• This patch should be committed to a new 2.1.x branch and immediately tag 2.1.0-beta1.
• We only need to support 2.0.x until Drupal 11.1.x goes EOL. Until then, anything that targets 2.1.x needs to be cherry-picked or backported to 2.0.x, and vice-versa.
• Both branches will release simultaneously. (IOW, when 2.0.0-beta2 is out, 2.1.0-beta2 will also come out.) The only real difference between these should be their minimum supported version of core.

This is postponed on the release of Drupal 11.2.

If this is going into a 2.1.x branch that requires 11.2, it should be fine to commit/tag/release that any time?

I left feedback on both MRs, mostly about the GitLab CI configuration.

If we don't worry about the PHPunit required in the Max PHP variant, this is RTBC.
If we want to fix that, then this is NW.

Setting to NW, but if we don't care about that, it can be changed to RTBC.

I guess this is tentatively RTBC? The failures in the max PHP variant don't seem to be related to Project Browser itself. From the logs:

  ERROR: PHPUnit testing framework version 11 or greater is required when running on PHP 8.4 or greater. Run the command 'composer run-script drupal-phpunit-upgrade' in order to fix this.

would it make sense to open up a follow up issue for comments and parts of documentation that are still using the term stage as a reminder? for core that is also handled in a follow up issue ( 📌 Update all comments and documentation in Package Manager to refer to "sandboxes" and related terminology Postponed ).

I think so, yes.

Created the followup 📌 [PP-1] Update all comments and documentation in Project Browser to refer to "sandboxes" and related terminology Active

OK, this is in on both branches, which is an effective SPLIT in support. 2.0.x will only support < Drupal 11.2, and 2.1.x is for Drupal 11.2 forward.

New code should be against 2.1.x first and then backported to 2.0.x. We intend to maintain support for 2.0.x until support for Drupal 10 is dropped.

Do we need a core follow-up to the 11.2.x branch, to explicitly conflict with versions of project browser < 2.1.0? I think this would prevent people updating core without also updating project browser if they're on a 2.0.x version prior to the commit here.

should the default branch also be set to 2.1.x, at the moment it is still at 2.0.x?

@catch, if core is willing to conflict with older versions of Project Browser (and, for that matter, Automatic Updates), then I'd gladly file that follow-up.