Issue #3454702: Revoke config page permissions when the type is deleted

Deleting a config page type left its permissions behind in every role that had them.

Reproduced on a running site: after deleting a type, the role config still listed view X config page entity and edit X config page entity, and Role::getAllValidPermissions() no longer contained them.

Core does not have this problem for its own bundles. BundlePermissionHandlerTrait adds the bundle as a config dependency to each generated permission, Role::calculateDependencies() picks it up, and Role::onDependencyRemoval() revokes the permission when the bundle goes away. This module built its permissions by hand and declared no dependency, so the role had no dependencies at all and nothing ever cleaned up. Verified the difference against a node type: deleting it revoked create X content automatically.

The permission handler now uses that core trait. On a running site the role gains a dependency on config_pages.type.<id>, and deleting the type leaves no permissions behind.

Sites that already deleted a type keep the orphans, because the dependency did not exist at the time. config_pages_update_10001() revokes them. It only touches permissions matching this module's own pattern whose type no longer exists, so unrelated permissions are left alone. Tested against a role holding two orphans plus access content: the orphans were revoked, access content was kept.

Two kernel tests cover it: the permissions carry the type as a dependency, and deleting a type revokes them from a role.

Note on the second part of the report, the leftover token reference: I could not confirm it. Config Pages tokens are generated dynamically from the existing types and nothing is persisted, so there is nothing to clean up there. If you still see a stale token somewhere, please add the details and we will look again.

Verified on Drupal 10.6.15, 11.4.5 and 12.0-dev: 296 tests pass on all three, PHPCS, PHPStan and CSpell are clean.