Scratch-blocks: Evaluate whether we still need the drag surface for workspace dragging

[picklesrus]

Before we introduced the drag surface (~3 years ago?) for workspace dragging, the idea was to just translate the svg directly when moving the workspace around. Revisit whether the drag surface is necessary. It'd be nice not to have to do that work of transferring the blocks at the beginning of a drag.

IIRC, one of the reasons for abandoning that approach was that blocks in the negative coordinate space didn't receive click events in Safari. After a quick test, that seems to be working now.

What I can't remember is how much coordinate work we'd need to do for this. There might be a can of worms... If there is, they should be more friendly worms than they were a few years ago. We've been studying them.

I also can't remember how much of a perf win it is.

[rachel-fenichel]

[rachel-fenichel]

Ooh, and if you want an unfriendly worm, check out the bobbit worm.

Or don't, if you don't want video of a kind of nightmarish sea predator, but they are cool.

[towerofnix]

An important factor for using a drag surface is that it lets us straightforwardly place a block above the rest of the Scratch editor. Just applying a translate to the block according to the mouse drag delta wouldn't work unless we could also display that block above everything else! (Keep in mind: When not being dragged, blocks are displayed below the flyout and are cut off by the border of the workspace div. When they are being dragged, they're above everything.)

We could use position: fixed in a similar fashion to what's done in #1895 - so basically the same math that's already used, but applied directly to the block elements instead of the drag surface. That'd probably take a bit of messing around with code (e.g. to make sure the block's position is restored properly once dropped - although this may already be mostly done by the existing code), but it'd get rid of the need for moving the block to a drag surface.