Create 'manage host' and 'administer host' permissions

Let's handle 'create host ... registration' permissions seperately.

The diffs look a little messy, partly because I found some semi-related things that needed tweaking, but mostly because some of the logic needed refactoring. But actually the changes here are very simple.

I suggest checking https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... first, just in case seeing everything laid out like that raises any bigger questions.

Having two operations differ by a single letter is likely to create confusion

Agreed. This got me thinking a bit more about operations.

And touches upon an inconsistency in our API I realised last night.:
- On the RegistrationHostAccessControlHandler we check $host->access('administer registrations', ... when we want to consider administer permissions when access checking operations like 'view registrations' etc. So host access hook fires twice, once with 'view registrations' and once with 'administer registrations'.
- But in RegistrationAccessControlHandler, in very similar circumstances, we check the administer permissions directly when evaluating 'view', instead of checking $registration->('administer',...
It's right and important that in the RegistrationHostAccessControlHandler we sometimes check $host->access('manage', which does cause a second firing of the access hook - this is an important point of extensibility. But the consistency with how we're treating administering doesn't seem quite right.

Sitting back, considering all this, and reviewing the access docs I wrote yesterday at https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... I have these thoughts:
- Operations should be 1:1 with the things users actually do.
- The 'manage registrations' host operation should be removed. It's not a real operation, just a consequence of being a bit literal when creating these operations based on existing permissions. Access checking for the /{host}/registrations route should depend on the user having access to either the 'view registrations' or 'manage settings' or 'manage broadcast' host operations.
- We should not create an 'administer registration' operation

Whether we should check the 'administer registrations' operation inside other host operations (or the 'administer' operation when checking other registration operations), rather than checking these permissions using a helper method instead of an operation, I'm not sure about. The downside of not using the operation (in both host and registration handler) is that if you customise a hook to give a user access to the 'administer' operation, it doesn't give them access to the 'view', 'update' and 'delete' operations automatically which you might expect, based on how the semantic of 'administer' is usually understood in Drupal access. Perhaps in #3464137: Make it possible to customise who can administer registrations we should have called the operation (on both registration and host) 'override settings' as that is what it actually is about.

I will wait to implement anything (in this issue or another) until I hear your thoughts.

What if the new permissions were per bundle, this would provide some separation, and has the nice side effect that they could become drop-in replacements for the soon to be retired "own" permissions.
Downside is loss of symmetry with the existing host permissions which are not per bundle.

I suggest not having these per bundle. I think having permissions tied to the host, and generic bundle permissions, provides a useful kind of orthogonality, and altogether I imagine it is more than sufficient for 99% of use cases. I think registration core is very generous in OOTB the permissions it provides; if starting from scratch I'm not sure we should be as generous as we are.

if there is a migration path for the "own" permissions.

If a user has the own permission for all registration types, we can give them the host permission. Otherwise, we have to block the module update using hook_requirements and require the sitebuilder to remove the own permissions and consider what permissions to give in light of their site's needs.

Note to self: I'm having doubt about the name "administer host registration". Need to consider naming carefully.

By the time this is released we could have close to 1,000 installs. Even if only 5% use an own permission varying by type, that is 50 sites that we have broken by removing functionality without a replacement. I don't want to do that. I don't have an alternative yet. Let's mull this over further.

Spitballing:
1. Add a hook_requirements warning now, wait until a major version release to remove. We can see how many people show up in the issue queue.
2. Keep them, mark them deprecated, add a hook_requirements warning, don't plan to do anything about it for years.
3. Create a legacy module that provides the permissions and makes them work as before. Make it a seperate project, not a child module, so you get stats on its usage and can eventually stop maintaining it. Or even mark it as not maintained, give them the responsibility.
4. Decide that we are not breaking anyone's site, they don't have to upgrade. Maybe make it a major version and keep backporting bugs to the previous version.
5. Keep the permissions around, but rename them "administer $type host registration settings" and mark them deprecated.
6. Create a "legacy" submodule that the sitebuilder enabled in an update hook if the site needs it.

I think it would be best to have a way of thinking that enabled breaking changes to be made to the module.

I think I need to create some follow-ups for some of the issues in #8 as well.

I think this is best postponed on #3500492: Check the administer operation when checking other operations