RegistrationAccessControlHandler should rely on RegistratonHostEntityHandler to consider the validation for edit access

To be honest, I don't really see why we have HostEntity::isEditableRegistration() and its RegistrationisEditable constraint. It would see much more Drupal normal to just check close and status here in RegistrationAccessControlHandler and have hook_registration_access as the customisation mechanism.

It's good to allow the host to have an opinion here. But the host's opinion shouldn't consider the specifics of the registration, only the specifics of the host. Considering the specifics of the registration is the job of RegistrationAccessControlHandler with hook_registration_access() as its customisation mechanism.

The best way for the host to have an opinion is to add these close and status checks into the 'edit registrations' host op. This doesn't worrk currently because of the way we call host operations from RACH as currently we do:

    // The "host" permission grants access if the user can edit the host entity.
    if (($result->isNeutral()) && ($host_entity = $entity->getHostEntity())) {
      $result = $host_entity->access($operation . ' registrations', $account, TRUE);
    }

We could treat the 'update' operation different and use andIf() for that case. Or, we could change the way we call all host operations to use andIf, and have the host handler return allowed by default instead of neutral by default. We have noted that host handlers can't currently block access, which feels like something they should be able to do, so something needs to change here anyway for more than the 'update' operation.

Inside the host handler, we could call the validation in the way that HostEntity::isEditableRegistration() currenly does. But actually that feels pretty eccentric to me. I'd just check the status and close directly in the Host access handler and not use validation for this.

Closing this since the need for "isEditable" and its constraint may go away, or at least change, depending on what happens in [#15966573]. So I'm going to let that issue handle it.