fix: Improve navigation and movement looping behavior

[gonfunko]

The basics

• I validated my changes

The details

Resolves

• Fixes [v13.0.0-beta.0] Workspace position for blocks with constrained move positions #9706
• Fixes [v13.0.0-beta.0] Keyboard looping configuration #9707

Proposed Changes

This PR makes several improvements around keyboard-driven movement and navigation:

• Looping now defaults to on
• The prompt to try unconstrained move mode when a block is moved to the workspace as a top-level block in constrained mode is now only shown once per session
• When blocks are moved to top-level blocks during constrained mode, their position is offset from their prior position to make it clearer that the proposed drop location/state has changed
• Constrained move mode now respects the keyboard navigation looping setting

[maribethb]

I think it is worth thinking through if there is a possible better approach to handle adding the workspace as a "stop" in constrained move, since it has added complexity here. But if you think about it and don't have any better ideas, this LGTM.

[maribethb]

Is it possible to differentiate this case from the case where a block was already on the workspace? There are two scenarios in this else clause:

1. You are doing constrained move of a block that has multiple positions to go to, and the current position happens to be the workspace stop, but if you keep moving the block in constrained mode (with looping on, or move back the way you came), the block would in fact move somewhere else.
2. You are doing constrained move of a block that has nowhere else to go, so constrained move does not do anything because there are no other connection points.

You've improved the behavior by only showing the hint once, but I think that ideally scenario 1 would not show the hint at all. If this is too complicated to do in this PR, I would be fine submitting this as an improvement and filing a bug to follow up with this.

Edit: kept reading the rest of the PR and you are doing some work related to differentiating these, so maybe you can reuse that work here

[maribethb]

this magic number should probably be a constant, don't we already have one for the amount a block moves in unconstrained mode? i would use that

[maribethb]

The amount of work you're doing to figure this out does make me wonder if it means there's a better approach than including the workspace in the list of possible places to go, but you'd have to talk to Mike about how he implemented that to see if y'all can work out something better.