Support aligning lanes to x or y axis during creation

[xiyuoh]

Targets one of the QOL items in #337.

This PR adds support for lane alignment - when creating lanes, pressing ShiftLeft would "lock" the end anchor transform such that the created lane would be aligned to the X- or Y- axis, depending on the cursor displacement from the start anchor. Releasing the button "unlocks" the alignment.
Hovering over an existing anchor also "unlocks" the lane alignment, so users can still select existing anchors even if the ShiftLeft button is pressed.

Changes also include updating the create_edges workflow to pass around a new ButtonInputType struct from KeyboardServices. This allows us to differentiate between pressed, just_pressed and just_released button interactions from within the workflow.

[mxgrey]

Similar to my feedback on multi-select I don't think we should monitor LeftShift directly to decide whether to be in alignment mode.

One simple approach that would at least be somewhat better is to have a CreationSettings Resource with a field like direction_alignment: Vec<Vec2> which gives a list of directions that the lane should align with. If empty then there is no alignment constraint. Separately we can have the keyboard system monitor the left shift and update CreationSettings while the workflow is running.

We should also give CreationSettings a fn reset() and call it during cleanup to make sure the settings don't leak into other modes.

[luca-della-vedova]

I tried this on a "low FPS" machine and noticed that there is a one frame delay between the lane update and the snapping feature, which makes the lane a bit wobbly and not clearly snapping to one axis when dragging, as shown below:

Screencast.From.2025-10-24.10-14-06.mp4

On a more personal opinion that can be argued against I wonder if it would make sense to change the transform of the cursor itself instead of only the anchor? The main reason is that there is now a mismatch between the position of the cursor indicator (the rotating circle) and the anchor that is being placed.
Edit perhaps this could also address the frame delay issue since the position of the anchor is based on the cursor, but at the same time could have unintended consequences if we have two different systems updating the cursor transform so not too sure still

[xiyuoh]

@luca-della-vedova your intuition was right, setting the transform of the cursor frame directly helps with the latency!

[xiyuoh]

Closing in favor of #420