Consistent entity delete access among entity forms, operations and actions

Problem/Motivation

The initial problem here is that as of Drupal 10.2 (or even earlier?), the delete entity operations on entity list builders are using ajax links, which open the delete confirm step inside an ajax dialog. The code altering the delete forms in \Drupal\wse\Core\EntityOperations::entityFormAlter is just denying access to the form, which in case of these ajax dialogs will cause the confirm form in the dialog to appear empty.

The delete operation link shouldn't be displayed accessible at all in such cases which would be consistent to the entity delete access which calls \Drupal\wse\Core\WorkspaceInformation::isEntityDeletable().

There's also some discrepancy between what \Drupal\wse\WseDeleteAction::access() is doing and the isEntityDeletable() method, but the underlying check should be the same.

Steps to reproduce

On Vanilla Drupal 10.2.x

• Install wse
• In the live workspace, create an article
• Switch to the "Stage" workspace and edit the article, save it
• Switch back to the live site and head to "/admin/content"
• There will be a Delete operation for the content which will open an empty dialog without any buttons when clicking it

Proposed resolution

Implement hook_entity_operations_alter() to ensure that entities which are being edited inside a workspace won't show the delete operation in the first place.

This should actually already be covered by entity access, but unfortunately for example the NodeAccessControllerHandler overrides EntityAccessControllerHandler in a way that prevents altering of the operations (which do actually check entity access in \Drupal\Core\Entity\EntityListBuilder::getDefaultOperations()) based on access checks because it returns early without invoking hook_entity_access() if a user has the 'bypass node access'. Thus altering the operations is more feasible here.