Standardize how we talk about OSRM

Our current nomenclature can be a bit confusing to newcomers because we use the term "OSRM" rather liberally when not intending to refer exclusively to OSRM routing. In particular our OSRM response parser and models are not actually specific to any vendor, and are more of a loose union of all the extensions that we're using, modeled as optional parameters.

We had a discussion about this on Slack and decided on "extended OSRM" as a general term where we are intentionally broad and expect to support either OSRM itself or something that "looks like an OSRM response."

Turned into a statement, here's what we'll refactor to:

> `createExtendedOsrmResponseParser` is a function which creates an `ExtendedOsrmResponseParser`. This object implements the `RouteResponseParser` trait and is capable of handling both the “original” OSRM format and common extensions to it, including voice and banner instructions in the format popularized by Mapbox.