[META] Access & validation refactoring

Problem/Motivation

There's a set of access-related issues I'm opening up. It's not obvious yet what their seperate scopes are, which ones need to be doe together, and in what sequence.

This issue is a parent for them, and to discuss overall strategy.

Issues

These are listed in the order I believe they should be tackled.

#3465637: Fix access cacheability
Addresses a range of minor problems with cacheable metadata of access results in RegistrationAccessControlHandler, RegistrationSettingsControlHandler, and ManageRegistrationsAccessCheck. Significantly refactors the access logic in these classes.

#3464137: Make it possible to customise who can administer registrations
Adds an 'administer' operation for registration entities.
May allow the 'administer own $type registration' permission to grant validator & override admin access on registrations the parent has host edit access for.

#3464717: HostEntity::isUserRegistered() and isEmailRegistered() don't consider edge cases is not really an access issue, and can move ahead independent of any other issue.

#3464498: Add a host access handler
Seeks to centralise and DRY access checks that consider the host entity, using custom operations, and provide a hook to allow customisation.

#3464736: Replace HostEntity::isEnabledForRegistration
Suggest replacing isEnabledForRegistration() with methods that can be used in access checks.

#3464134: Access control allows non-admins to edit registrations on disabled hosts
Identifies a UX bug where the user is allowed to access a registration create/edit form and enter values, but any attempt to save the form fails validation because the host is not enabled.

#3461152: Create registration permission does not exist
The permission is supported in the code but does not exist in the permissions configuration.

#3464704: Refine semantic of 'administer own $type registration' permission
Tackle the confusing semantic of 'own' in this administer permission.

#3500492: Check the administer operation when checking other operations
Our approach to 'administer' and 'administer registrations' is inconsistent.

#3500491: Remove the 'manage registrations' operation
Operations don't need to map 1:1 with permissions, it's not the right way to think of them.

#3479435: Create 'manage host' and 'administer host' permissions
Add new permissions like 'administer host registration', 'manage host registration' and 'create ... host registration'.

#3493421: Remove "administer own $type_id registration settings" & "manage own $type_id registration"
Postponed until 4.0: Remove these existing permissions with unusual meaning of 'own', in favor of the new host permissions.

#3479430: Administer bundle permissions should allow registration creation
Make 'administer $type registration' give exactly the same access as 'administer registration' but only for the type.

#3494643: Integrate "edit $type registration state" into access handler
Deal with these unusual permissions that were left out of #3464498: Add a host access handler.

#3494658: Add 'create * host permissions'
When Drupal core unblocks us, we can add create permissions based on host.