fix: dragging and disposing of shadows

[BeksOmega]

The basics

• I validated my changes

The details

Resolves

Fixes #8171

Background

This handles shadow block dragging behavior in a very non-generalized but backwards compatible way. As far as I can think, there's no way for it to be both generalized and backwards compatible, so I chose backwards compatibility.

Our requirements are:

1. We need shadows to be the thing being dragged, so that custom draggables can duplicate instead of dragging shadows.
2. We need non-customized shadow blocks to drag their parent blocks.
3. We need non-customized shadow blocks to dispose of their root blocks when they're dragged over a delete area.

Our constraints are:

1. We can't change the signature of dispose in IDeletable because it would with the block dispose parameters.
2. We can't change anything else about IDeletable either because because it would be breaking.
3. We can't change what we expect to be returned from IDeleteAreas. It is not technically binary breaking, but changing what we expect could be behaviorally breaking, the worst kind of breaking.

So unless we want to break something, our only option is to special case for blocks for now, and reevaluate for V12.

Proposed changes

So what we're doing is passing the root block to any delete area callbacks, and we're also disposing of the root block. Any draggable-specific hooks are still called on the draggable itself, not the root.

If the draggable is not a block, we just always use the draggable.

Testing

Manually tested:

• Dragging shadows
• Dropping dragged shadows over delete areas
• Setting a duplicate-on-drag drag strategy on a shadow blocks duplicates the shadow on drag

[rachel-fenichel]

I can see why you don't like the conflict between backwards compatibility and generality, but this looks like a reasonable solution for now.