Consider splitting the pathfinder from the map model

Currently the pathfinder is baked into the `Map` and generally kept up-to-date as the map is edited. While that has been working great for the original traffic sim, there's been some friction with more recent projects.

- for Ungap, we want smaller map files (#746) to improve loading times. Lots of the large pathfinding graphs aren't even used. We wound up with `Map::minify` to strip out some of them
- the LTN tool is mostly not using the built-in contraction hierarchies at all; it overrides roads to avoid and an avoid_main_road parameter almost always
- recalculating the pathfinder in main edit mode has to happen at the "right" time -- before we need it, but after a potentially long chain of edits
- reasoning about the baked-in pathfinder is getting confusing in the LTN tool. We're thinking about lifetimes. There's `Pathfinder::new_limited`, `clear_custom_pathfinder_cache`, and other things to manage combinations of RoutingParams and Dijkstra/CH engines
- in the LTN impact tool, we _do_ want to build a contraction hierarchy with custom params. I started trying to do that, but got lost in a `RwLock` mess

So what am I thinking about? Splitting out the pathfinder from `Map` entirely -- both as a struct and as files. This wouldn't be unprecedented. We bundle `Map` and `DrawMap` and keep them in sync today. And file-wise, we have different `Scenario`s for some maps.

More generally, the monolithic map model isn't holding up. We have debug options to retain OSM building tags, but strip them out normally. Some tools would be better off with buildings removed entirely for performance reasons. Some maps have extra languages per road. Perf and file size wise, I think "pay as you go" would make more sense.

The cost is complexity. Loading a sequence of files in the UI is a headache right now, because we don't really have real async support. And keeping bundled state gets a bit harder -- when we store the unedited map in the traffic sim, now we also need to remember its corresponding pathfinder.