Improving the UX of editing routes

[Sparrow0hawk]

As noted in #202 (comment) I found the UX of editing routes especially when appending to routes is not the default slightly clunky and easy to accidentally delete red waypoints when trying to grab and move them.

I'd propose exploring the feasibility of:

• Change the interaction that triggers a waypoint deletion i.e. right mouse click?
• Make a click on a waypoint make it sticky to the cursor, so I don't have to drag I can just click and move it about (realise this would depend on changing waypoint deletion event)

It would also be worth getting some user feedback on these features to see how they'd like this to behave too.

[dabreegster]

Change the interaction that triggers a waypoint deletion i.e. right mouse click?

This sounds like the easier option in the short-term to me. Per maplibre/maplibre-gl-js#2593 (comment), right click may not be good from an accessibility perspective. Also as a sanity check -- can it be done on mac?

Make a click on a waypoint make it sticky to the cursor

This feels like it'd be intuitive to me, but not sure how we can predict if this'll be the right option without implementing it and doing a UX study.

And unfortunately, I'd rate the difficulty of this code change as moderate. Same reason as #159. I've been toying around with a way to visualize the states / interactions of all of our drawing tools, so we can express something like "state = added two points, action = click existing waypoint, effect = change to dragging waypoint state" both in a finite state machine diagram that's understandable to a UX designer, and to make the code more maintainable and testable (fuzzing states X interactions!)

[dabreegster]

Some notes in dabreegster/route_snapper#13 about summarizing current behavior as a finite state machine. It's a difficult exercise, maybe not helpful.

dabreegster/route_snapper#33 starts some unit tests. I want to get these covering all current behavior and use test-driven development for some of the next improvements we make, especially #159 (because it feels like an explosion of possible states to me, even fuzz testing could be an idea to consider)