Mode shift

Quoting [some docs](https://dabreegster.github.io/abstreet/trafficsim/travel_demand.html#modifying-demand): The travel demand model is extremely fixed; the main effect of a different random number seed is currently to initially place parked cars in specific spots. When the player makes changes to the map, exactly the same people and trips are simulated, and we just measure how trip time changes. This is a very short-term prediction. If it becomes much more convenient to bike or bus somewhere, then more people will do it over time. How can we transform the original demand model to respond to these changes?

Here's a strawman proposal for how this could work: after the player edits the map, re-evaluate every trip in the scenario. Calculate a cost for driving/walking/transit/biking for each one. Change the mode specified by the input to the best choice.

- From a gameplay/UI perspective, I'd vote for explicitly opting into this new "long-term" behavior vs the current short-term mode.
- We may want to do this upfront before any map changes to avoid the first edit causing many spurious changes unrelated to the edit. If the Soundcast model predicts a particular mode for someone and our calculation changes it, what should we do -- go ahead and change it?
- If the person doesn't own a car according to the input, it might be odd to assume player edits would cause them to buy one. But going the other direction is much easier for people financially, of course.
- How well this idea works completely depends on how we cost each possible route. Do we express the cost just as an estimated time? If we wanted to account for some kind of safety/convenience, how do we compare these -- some linear combination with parameters we have to somehow tune? Or a lexicographic comparison of each factor, arbitrarily choosing that a slight safety benefit warrants any increase in expected time?
- Currently the pathfinding costs for all modes are quite primitive -- they don't account for waiting at traffic signals, unprotected left or right turns onto an arterial, any other measure of how nice a road is to cycle/walk on, etc. It's becoming increasingly urgent to improve this, not just for this issue.
- A person's individual preferences differ, which should likely affect how they cost each mode. How should we encode these preferences? Does Soundcast contain them?

Thinking a little about UX of switching modes.
- Even with contraction hierarchies, calculating 4 paths for every trip will be slow -- depends on the map and scenario size, but could be 30-90s sometimes. Likely need to think carefully about aggregating similar trips to speed this up.
- #237 has some ideas for helping the player understand these long-term changes.