fix: Factor out workspace drag methods into utils.

[johnnesky]

The basics

• I validated my changes

The details

Resolves

Fixes #7926

Proposed Changes

This PR transfers the logic from WorkspaceSvg methods startDrag and moveDrag into a new utils file. It further factors out some shared coordinate math into a private function. It removes the private property dragDeltaXY from WorkspaceSvg (is this a breaking change?) and replaces it with an internal map from workspace to delta.

Reason for Changes

This feature is used by block comments and workspace comments, but is not generally used by workspace objects and thus is not really appropriate for WorkspaceSvg.

Test Coverage

Manually dragging and resizing comments seems to work as expected. I don't believe any existing tests directly call these methods on a workspace, maybe some do indirectly, but FWIW all existing tests pass.

Documentation

N/A

Additional Information

Is removing a private property considered a breaking change?

[cpcallen]

Since I don't really know what a ScreenCTM is the following question is probably nonsense, but: can the post-mouseToSvg fixup be avoided by passing a better value as the third parameter of mouseToSvg?

And if so would such a change be beneficial?

(Side note: looking at the definitions of mouseToSvg and getInverseScreenCTM, it appears that it mightalternatively be possible to completely omit the third parameter to mouseToSvg with no change to the returned valuest—but perhaps that would be less efficient, since getInverseScreenCTM seems to do caching.)

[johnnesky]

I think, in some sense, the "correct" thing to do would be to pass workspace.getCanvas() as the second argument, to derive the transform matrix from the block canvas which should incorporate the zoom. However, the SVG APIs that mouseToSvg uses require an SVGSVGElement (<svg>), whereas the block canvas is a <g> element.