Allow global default admin language by making admin user language negotiation options configurable

Adde screenshots of changed UI.

Pushed initial implementation to MR.

Adding one more screenshot.

Also add LLM disclosure.

I realized we don't quite allow the user to change the admin language itself (of the site), we allow them to set their own. This actually allowed to simplify this setting UI more as we don't need to explain what the checkbox means when its label is correct :D

     $form['allow_user_change'] = [
       '#type' => 'checkbox',
-      '#title' => $this->t('Allow users to change the administration language'),
+      '#title' => $this->t('Allow users to set their own administration language'),
       '#default_value' => $config->get('admin_language.allow_user_change') ?? FALSE,
-      '#description' => $this->t('If checked, admins can set their own administration language preference on their account page.'),
    ];

I am further simplifying the help text on the config page so it is an easier read but also contains more accurate info at the same time :) \

-        $output = '<p>' . $this->t('The administration language applies to pages and interface elements that are accessible to users with the <em>Use the administration pages</em> or <em>View the administration theme</em> permission.') . '</p>';
+       $output = '<p>' . $this->t('Applies to administrative interfaces accessible to users with <em>Use the administration pages</em> or <em>View the administration theme</em> permission.') . '</p>';

And a matching screenshot.

Test fails uncovered tests that just needed updating to cover the new situation. The test scenarios were there that we need just the results are now slightly different.

Also tests uncovered a performance regression introduced which can be resolved with different code ordering. I added a comment to the code to ensure that stays as-is (although performance tests would also flag it later if we change it).

This will be much closer to passing tests if not passing tests :D

Now fully passes tests. The existing test coverage was actually very comprehensive, it is just that now the results are slightly different. There is a lack of fallback of language negotiation when on admin page, if the admin language negotiation method is set and it is an admin path then that decides it. I think that is intended. Otherwise the fallbacks are the same :)

So I think this is entirely complete with tests and all.

Documented the behaviour in release notes snippet.

Adding before screenshots for those not well versed in negotiation screens.

@lauriii: I don't feel strong about that description either, I think its more of a mistery what it applies to if we don't explain it but we did not explain it before either, so we don't necessarily need to explain it to introduce the site level default as well. Also adjusted the labels in the form a bit to make it simpler / more consistent and resolved a comment from @borisson_ and rebased on main :)

One thing that I need to call out is that this improvement makes Drupal use the possibility to fall back from the admin language to other negotiation methods like path prefix. So before this MR it was possible to configure that the user can have an admin language but if they don't have one then the further methods worked (eg. you can view the admin site in any language based on the path prefix). After the current state of the MR if the negotiation method is enabled and the user does not have a preference, it always picks a specific language, does not fall back on eg. path prefix.

In other words if you want user preference for admin language then you can't have it without a site level certain value, while before this MR that was not certain and could still depend on path prefix for example. Should I add that feature back? (That would be an option to let the global select box define 'No global admin language' or something).

After pondering more on this, I realized for sites updating we definitely don't want to disrupt them, so I added "back" the pre-MR behaviour of not necessarily having a global admin language. Issue summary needs update, but changes look good locally etc :)

Following discussions with Lauri I rolled back the backwards compatible empty option for the default global admin language (which would have allowed to enable only user based preference and no global admin language preference, therefore would have fallen back to further negotiation methods). This also means the issue summary is up to date and is ready for reviews again.

If we want to make admin language more configurable or allow it to be more configurable, one option could be to add an "Administration language" negotiated thing where admins can prioritise options similar to how they can now for interface language and content language. Then admins can add arbitrary methods there. That may be overcomplicating things though. Creating a contrib module to be able to alter this would require swapping this negotiation method definition using hook_language_negotiation_info_alter, but is possible if the swap is one to one.

Fixed remaining test issues to green. I think this is complete with the behaviour change explained :)

Thanks for the review. Rebased MR is green again, applies cleanly now.