Prevent :remove_{group,project} when ancestor is scheduled for deletion

What does this MR do and why?

Second attempt after Revert "Merge branch 549074-marking-a-group-as-... (!202830 - merged) reverted Prevent :remove_{group,project} when ancestor i... (!201716 - merged).

This change adds more granular control over deletion permissions for groups and projects in a hierarchical structure.

Previously, the system would prevent certain actions if either the item itself OR any of its parent items were scheduled for deletion. Now, the code can distinguish between these two scenarios - it can check if just the item itself is scheduled for deletion versus if a parent/ancestor is scheduled for deletion.

The main improvements include:

• Added an optional parameter to exclude the current item when checking for deletion schedules in the hierarchy
• Updated permission rules so that users cannot remove groups or projects when a parent is scheduled for deletion (even if the item itself isn't), unless the parent is being deleted (meaning that the deletion process has started, so we need to allow the :remove_group/:remove_project policy). This last condition is new compared to Prevent :remove_{group,project} when ancestor i... (!201716 - merged) and fixes a regression reported in Cannot permanently delete subgroup with project (#565617 - closed).
• Modified the deletion checking logic for groups/projects to only look at ancestors, not the group/project itself
• Added comprehensive tests to verify these new permission rules work correctly

This prevents users from accidentally removing items when their parent containers are already scheduled for deletion, while still allowing normal operations when only the item itself is scheduled for deletion.

References

• Related to Marking a group as 'pending deletion' should di... (#549074 - closed) • Rémy Coutable • 18.4
• Related to Cannot permanently delete subgroup with project (#565617 - closed) • Rémy Coutable • 18.4

How to set up and validate locally

1. Mark a group for deletion
2. Check that a child group or project cannot be marked for deletion itself as long as their parent is marked for deletion
3. Force-delete the group and ensure that the deletion goes through. The group, and its child group/project should all be deleted

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.