Incorporate LTN edits into map_model

#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 `EditCmd`s 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.