Optimise the router for GUI use

[skinkie]

Typically the user spends more time while looking up a stop than the planning process takes. The planner, as we speak, has a very bad cold performance (when the memory is not paged from disk). While the hot performance is very acceptable.

• While typing the first stop, we could scan through the data file, and load the data in the background.
• When the typing is done, we could already do the first step of the routing.
• While typing the second stop, we could prime the results based on the distance (in time) from the first stop.
• While typing the second stop, we could show the distance in time appended to the list.

[abyrd]

Time demand groups have improved the cold-start performance. However, searching from current location and time would still serve to both page in the data file and provide a prebuilt result tree giving instant results in the most common use cases. This should of course only be done if there is a separate UI and calculator thread, and we would have to be able to kill the search function call to keep the UI responsive in the event that different origin was entered.

When results are available, links should appear to render itineraries to the most commonly used destinations, perhaps even the most commonly used destinations from the current start location but that involves fuzzy spatial matching. We could possibly achieve such matching by storing a list of recent searches and inserting them in the hashgrid.