Add versioning requirement to Provider API

[oderby]

provider APIs must support versioning going forward. As implemented
here, we will use a custom media-type to negotiate the API version a client
and server will use. A couple reasons for taking this approach:

• API versioning will become important as 0.3.0 and future releases are
  published with breaking changes that Providers, cities and third-parties
  will need to implement/adopt on differing timelines.
• Because this is a specification for others (Providers) to implement
  their APIs against, mandating URI structure beyond endpoints could be
  burdensome or limiting. Conversely, leveraging standard HTTP Headers in
  a compliant manner places no limitations.
• Further, in practice, many providers have already begun implementing
  their own versioning in their registered mds_api_url.

Closes #114

[oderby]

I have a tendency to be verbose, and this reads as a bit more verbose than the rest of the spec, so happy to hear suggestions for making it more terse, in addition to general comments. Thanks!

[oderby]

Also, I didn't see any obvious way this needed could be tied into https://github.com/CityOfLosAngeles/mobility-data-specification/blob/dev/ReleaseGuidelines.md or the JSON schema, but let me know if I missed something.

[hunterowens]

I think headers should be the way to go, give that I don't want to touch endpoints URIs expect for the names.

If a provider feels like it, they could probably configure redirects to redirect requests from {mds_api_url}/{endpoint} with header: {some_version_number} to /{some_version_number}/{endpoint} in order to keep codebases as clean as possible.

Going to approve for now but pinging @noonhub for thoughts before I merge.