Incorporate LTN edits into map_model

[dabreegster]

#995 is about referring to roads, intersections, turns, etc using geometry and robustly handling upstream OSM changes. While thinking through how to make this change just for the LTN tool, I've been revisiting why the LTN proposal save file is different from the older map_model::MapEdits format. Another problem with the LTN savefile is that it currently writes all existing filters. We want a command-based approach to sanely handle undo/redo, reduce the size of the savefiles, and handle upstream changes to existing filters. That command-based approach already exists. I started LTN savefiles as something different from MapEdits in the beginning to iterate rapidly on unknown requirements, but now it's time to go back and make the formats / representations be the same.

So the change:

• Lift LTN concepts into map_model
  • Filters and crossings are optional (type, distance) tuples on a Road
  • Diagonal filters are optional on an Intersection
• Make new EditCmds to modify these things
  • Following the current approach, this'll probably be a blunt "set filters on road 123 to X" rather than a more granular "delete filter X", "add filter Y"
• Possibly move the LTN tool's "transform existing filters" step into the importer pipeline
  • But maybe not yet. This would affect the other A/B Street apps; they'd need to understand filters for rendering, pathfinding, A/B Street's detailed road editor mode, etc. Since that's a bigger step, maybe don't do this yet.

This won't quite let us replace the LTN savefile with the classic PermanentMapEdits just yet, because of boundaries / partitioning. I also want to stop saving all neighbourhood boundaries and only represent edits. But this is trickier, and I think first requires a big user-visible change to boundary management. More on that later.

This change is orthogonal to #995, and could be done in either order. But both together will be great, also because it opens the way for other people to produce and consume A/B Street edit files, without needing to understand a bunch of weird internal implementation details.

Alternative considered: reinvent map edits from scratch in the LTN crate

Since we're also switching to GeoJSON output and using geometry to ID things, I thought about starting from scratch with map edits for the LTN tool. But this'd wind up reinventing lots of logic that's already working fine in MapEdits, like compacting changes and efficiently applying a diff.

Alternative considered: base map edits v2 on top of osm2streets instead of map_model

osm2streets in many ways has been acting as a v2 of map_model, so maybe all these new ideas for map edits should be implemented there. Eventually I do want the concept of edits to live there, but not yet -- too huge a step. The LTN tool can't just rely on osm2streets today, because it needs areas, buildings, and file loading from map_model. #1041 would maybe be some intermediate step here, but it's not important yet.

[dabreegster]

In-progress at https://github.com/a-b-street/abstreet/tree/ltn_map_edits. High confidence I can finish this with another uninterrupted day of work!

[dabreegster]

• Check performance of map edits. (Resnapping buildings constantly is probably bad)
• The overall UX of saving / file management is still weird. Autosave would match user expectations much better and not be hard...
• The assigned proposal name is very strange, especially when forking a new proposal. (Note that new_edits can't generate unique ones -- different directory!)
• When we try to auto-filter an area, we no longer cancel empty edits
• We no longer batch together a bunch of filters added at once with freehand. Undo gets chunky/weird.