Reverse optimization about r5

[mattwigway]

Agh this gets really messy. Consider these two examples, both of which suggest a solution that won't work with the other.

1. You can ride to stop B now or wait five minutes and ride to stop B. If you wait, you miss your transfer to destination 1 but not destination 2. Thus if you're going to destination 2 you should wait, if you're going to destination 1 you shouldn't. The obvious solution is to just keep moving forward in time, using the RaptorState from the next minute, until you find one that doesn't arrive at the same time.
2. However, that breaks when you have frequency-based routes, which will have different random offsets in each iteration.

[abyrd]

I'd rather avoid any hacks even remotely resembling "reverse optimization". I think the only really defensible thing to do is to reverse all the paths found one by one, by actually doing a backward search. Considering how tight the constraints are (derived from the forward results), it might be acceptably fast. We'll need this capability for point to point trip planning searches anyway, and I'm wary of the code complexity that comes from trying to optimize this procedure before we've even implemented it in the obvious, simple way. Our calculations are already quite rapid, and this whole system is made to scale with workers added to the cluster.

We'd get all the minimum travel time bounds from the basic range-raptor search, then kick off a highly constrained range-raptor search backward from each reached stop. This makes for a lot of extra work, but would only be done on big batch jobs or if someone requested/needed route names for each path. Whatever implementation we use, I think this should be pulled out into a separate step that follows completion of the main forward search. I say this mainly for reasons of process clarity and structure, and maintainability: it's going to get very ugly if we factor increasing amounts of functionality directly into the RAPTOR search procedure. If we can express the process as many calls to the same method in opposing directions it will be clearer.

We will at some point need to consider/include suboptimal options for Modeify too.

[mattwigway]

We also don't need this for schedule-based networks, see #42.