Both proposal save files are way too brittle

A/B Street has map edits and the LTN tool has its own format for boundaries and filters. Both files currently reference OSM way and node IDs to refer to road segments. This is slightly better than the very original format, which used opaque `RoadIDs` that could change when import code slightly changed. The A/B Street map edit format even has backwards compatibility for the JSON schema itself, which is also non-trivial to maintain.

But the current format breaks constantly when downloading fresh OSM data, or with osm2streets transformations that merge or split roads, or when importing new footways. It's a serious headache to manually fix these up everytime, and if the LTN tool had lots of users, I'd be constantly breaking their save files.

So opening this issue to think about how to do better. Also very related to ATE schema (so CC @Robinlovelace).

# An initial idea

How can we refer to a road segment over time in a stable way? I think the only hope is to use geometry instead. To reference a road segment, we use the polyline of its center, not any OSM IDs at all. That means when we load it, we have to snap, and the result could be multiple road segments. We have to decide how to handle edits to lanes -- if the save file's "old" lanes don't match the new basemap, several choices how to resolve.

This gets much more complicated for LTN boundaries / partitioning. I want to rethink how all of that works anyway (#916). Maybe a boundary is just a polygon, we let users draw these freehand, and we have a darn good snapping process that can trace roads appropriately and find the interior. Maybe the individual block addition/deletion process can still be an option to refine, or maybe not.