Fix contributor removal concurrency bug

[verheyenkoen]

Bug description

Removing contributors from a publication/dataset works position based. This could lead to wrong data if two users decide to remove the same contributor at the same time (eg. during a meeting).

Steps to Reproduce

1. Open a publication/dataset with multiple contributors (authors/creators, editors & supervisors) in the contributor view.
2. Duplicate the page in a new tab.
3. From both tabs, delete the same contributor.
4. The result depends on which positional contributor you removed:
   • If you didn't remove the last contributor, two different contributors will have been removed. This is a big problem since the second person executing the remove, actually removed a different contributor than the one they clicked the delete button on.
   • If you did remove the last contributor, the second user to do so will see that the confirm dialog does not close and nothing is refreshed. The AJAX call to confirm the remove will cause an internal server error (that HTMX won't process) because they delete a contributor at a position that doesn't exist.

Risk classification

Likelihood

2: Probable

Consequences

2: Critical

Expected behavior

Not sure if we also want to show the concurrency error dialog here (for the second user executing the remove), or if we just want to refresh the contributors with the current state, which is the state that the user expects anyway.

Additional context

Bug discovered while working on reordering concurrency bug (#1568).

[verheyenkoen]

Tests prepared on branch fix/contributor-removal-concurrency-bug. Draft PR already opened: #1702

[verheyenkoen]

Found an additional problem here (probably caused by the same bug): when one user reorders contributors and another user removes a contributor from an unrefreshed view, the wrong contributor is removed. This should result in a conflict error dialog I guess and force the second user to refresh first.