Closes #2663 - Allow multiple access schemes with Workbench Access

[akslay]

Description

Adds a patch that addresses a bug preventing you from having multiple access schemes in combination with the "Deny access to unassigned content" setting.

Related issues

Closes #2663

How to test

In a fresh QS build (not using this PR):

• Install Workbench Access
• Add 2 user accounts for testing, and assign them the "Content Editor" role (not "Content Admin")
• Set up a couple sections on the website (or use AZQS demo content)
• In Workbench Access settings, enable the "Deny access to unassigned content" setting
• Create an Access Scheme, using menus, for one section of the site, and assign one of your users to it
• Create another Access Scheme, using menus, for another section of the site, and assign your other user to it
• Use Masquerade to try editing the 2 sections of the site using both editor accounts.

This test should fail (i.e., user assigned to section 1 shouldn't be able to actually edit it)

In Probo build:

• Install Workbench Access
• Add 2 user accounts for testing, and assign them the "Content Editor" role (not "Content Admin")
• Set up a couple sections/pages on the website (or use AZQS demo content)
• In Workbench Access settings, enable the "Deny access to unassigned content" setting
• Create an Access Scheme for one section of the site, using menus, and assign one of your users to it
• Create another Access Scheme for another section of the site, using menus, and assign your other user to it
• Use Masquerade to try editing the 2 sections of the site using both editor accounts

You should now be able to edit the appropriate sections, and be denied to the appropriate sections.

Types of changes

Arizona Quickstart (install profile, custom modules, custom theme)

• Patch release changes
  • Bug fix
  • Accessibility, performance, or security improvement
  • Critical institutional link or brand change
  • Adding experimental module
  • Update experimental module
• Minor release changes
  • New feature
  • Breaking or visual change to existing behavior
  • Upgrade experimental module to stable
  • Enable existing module by default or database update
  • Non-critical brand change
  • New internal API or API improvement with backwards compatibility
  • Risky or disruptive cleanup to comply with coding standards
  • High-risk or disruptive change (requires upgrade path, risks regression, etc.)
• Other or unknown
  • Other or unknown

Drupal core

• Patch release changes
  • Security update
  • Patch level release (non-security bug-fix release)
  • Patch removal that's no longer necessary
• Minor release changes
  • Major or minor level update
• Other or unknown
  • Other or unknown

Drupal contrib projects

• Patch release changes
  • Security update
  • Patch or minor level update
  • Add new module
  • Patch removal that's no longer necessary
• Minor release changes
  • Major level update
• Other or unknown
  • Other or unknown

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[joeparsons]

I noticed some coding standards and D10 compatibility issues with the existing patch. Could switch to this newer patch I added to the issue?
https://www.drupal.org/project/workbench_access/issues/2982550#comment-15194961

Also, the patches section is supposed to be alphabetized (by project name). Could you move the new patch definition within the patches section so that it is in the correct alphabetical order?