Improve handling of the 'in_trash' query parameter

There's a couple issues that needs to be addressed here with the new permission checks, I'll try and push my fixes up in due course:
1. Optimization: Only check the permissions if the $event->getRequest()->query->has('in_trash') is TRUE.
2. There's a very specific edge case involving multilingual sites and the domain_config_ui module where as per the comments the trash ignore context will not work (even for users with the necessary permissions) because the ParamNotConvertedException is thrown during the permission check and because the language negotiation happened to be called before ours. It also only gets triggered if the user has a preferred "Administration pages language" specified in their user profile.

Steps to reproduce edge case

1. Have a user with the access administration pages or view the administration theme permission.
2. Give them a preferred language code.
3. Have something trigger the language negotiations before the \Drupal\trash\EventSubscriber\TrashIgnoreSubscriber::onRequestPreRouting() listener is called.
4. Attempt to access the deleted /node/{node}?in_trash=1 route as that user.

One "easy" fix (but seems more like a hack) is to increase the prerequest event listener priority so it's as close to 300 as possible by passing a float string (we can't mix floats and integers in an array index, so it has to be a float string) for the priority (that way, it always runs before any other event subscribers with a priority of 299):

  /**
   * {@inheritdoc}
   */
  public static function getSubscribedEvents(): array {
    // Our ignore subscriber needs to run before language negotiation (which has
    // a priority of 255), but after the authentication subscriber (which has a
    // priority of 300) in order to allow route enhancers (e.g. entity param
    // converter) to load the deleted entity.
    // If the "domain_config_ui" module is installed, it's possible that when
    // the system.timezone_resolver::setDefaultTimeZone() subscriber is called
    // (priority of 299), domain or any other contrib modules may call the
    // language negotiation earlier than expected whilst overriding the config
    // factory, so we need to ensure that this listener is called immediately
    // after the authentication subscriber to ensure the user has the
    // appropriate context.
    $events[KernelEvents::REQUEST][] = ['onRequestPreRouting', '299.99'];

But I think the "cleaner" fix is something along the lines of this (or do we keep both, to ensure the onRequestPreRouting behaviour is always consistent):

    // ...
    $events[KernelEvents::REQUEST][] = ['onRequestPreRouting', 299];
    $events[AccountEvents::SET_USER][] = ['onSetAccount'];

That way, we're also able to react to situations where a user account is switched multiple times within the same page request, so we may disable/enable the trash context as necessary.

I'll try and push those fixes up and add a potential kernel test to replicate the edge case issue if I have the time to.

edit: on further thoughts, having the '299.999' priority might not be a hack, and just the way to do it. I think it's cleaner than trying to alter the event listener order to ensure the trash module is the first of the subscribers with a priority of 299 to be ran, and if that breaks in the future for whatever reason, then it can be addressed.

Pushed an update addressing the edge case, including a test case showcasing the 404 behaviour when the language negotiation is triggered earlier than the trash module expects.

The test-only changes pipeline is failing as expected.

For the second part, I'm fine with both options. If the string float "hack" works, it's not the worst code needed for Trash to do its job.

The hack only worked for older versions of Drupal using Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher, from 10.3.0, it's handled by the symfony event dispatcher, which enforces the priority as an int.

I've addressed the event subscriber priority issue through the service provider and adding a subscriber to enforce the appropriate trash context as soon as the account is switched to (useful for things like masquerade) - the account set listener alone might be sufficient to fix the bug (haven't tested), but I think it's still good to keep the logic as a means of addressing other trash ignore priority precedence issues in the future (in the event even the account switch priority might need a specific value).

Addressed the feedback and test case for if the state was originally 'inactive' before the user was logged in.