Move debug timing to RoutingWorker and adapt to OTP2 routing phases

[hannesj]

This makes DebugOutput use the new routing phases in OTP2, and updates their calculation. Previously a time of 0ms was reported for everything, as the DebugOutput object was not used in the routing worker.

To be completed by pull request submitter:

• issue: Link to or create an issue that describes the relevant feature or bug. Add GitHub keywords to this PR's description (e.g., closes #45).
• roadmap: Check the roadmap for this feature or bug. If it is not already on the roadmap, PLC will discuss as part of the review process.
• tests: Have you added relevant test coverage? Are all the tests passing on the continuous integration service (Travis CI)?
• formatting: Have you followed the suggested code style?
• documentation: If you are adding a new configuration option, have you added an explanation to the configuration documentation tables and sections?
• changelog: add a bullet point to the changelog file with description and link to the linked issue

To be completed by @opentripplanner/plc:

• reviews and approvals by 2 members, ideally from different organizations
• after merging: update the relevant card on the roadmap

[t2gran]

My main comment here is that the DebugOutput plays two roles and should be split into a plan DTO
located in the org.opentripplanner.api.resource and a sevice witch do the timing and aggregates the results , and in the end produces the DTO. Maybe DebugAggregatoris an ok name for the service in lack of a better one. I would put it in the org.opentripplanner.routing.framework package. I could not find an existing good candidate.

If we do so, we get one LOGGER we can turn on/off for perfomance logging and the concerns are separated.

[t2gran]

This looks as a good start. JavaDoc on some public classes is missing.