Add support for OSBAPI 2.14

[teddyking]

We'd like to get this client up to date with the current version of the OSBAPI spec (which is currently on 2.15). This is an interim step to add support for 2.14.

Below is a list of the 2.14 release notes. We plan to look at each feature and determine if the feature has already been implemented or if new changes are required.

Feature	Current Status
Added Opaque Bearer Tokens to the Platform to Service Broker Authentication section (PR)	DONE
Added Content Type guidelines	DONE
Added GET endpoints for fetching a Service Binding	ALPHA
Added support for asynchronous Service Bindings (PR)and a new last operation endpoint for Service Bindings endpoint	ALPHA
Added GET endpoints for fetching a Service Instance	ALPHA (#145)
Allow an updated dashboard_url to be provided when updating a Service Instance (PR)	ALPHA
Added clarity around concurrent updates (PR)	N/A
Added clarity on how Platform's can clean up after a failed provision or bind (PR)	N/A
Provided guidance for CLI-friendly names (PR)	N/A
Allow for uppercase characters in Service and Service Plan names (PR)	N/A
Clarify that extra fields in requests and responses are allowed (PR)	N/A
Added an OpenAPI 2.0 implementation	N/A
Allow for periods in name fields (PR)	N/A
Removed the need for Platforms to perform orphan mitigation when receiving an HTTP 408 response code (PR)	N/A
Moved the dashboard_client field to Cloud Foundry Catalog Extensions	N/A
Added a compatibility matrix describing which optional features in the specification are supported by different Platforms	N/A
Added clarity for returning Service Binding information via the GET endpoints (PR)	N/A
Added guidance for supported string lengths (PR)	N/A
Clarified that the plan_updateable field affects modifying the Service Plan, not parameters (PR)	N/A
Clarified which Service Plan ID to use for polling the last operation endpoint after an update (PR)	N/A
Clarified Platform behaviour when a dashboard URL is not returned (PR)	N/A
Fixed an incompatible change introduced in v2.12 (PR)	N/A
Added clarity around the state of resources after a failure (PR)	N/A

• DONE = Feature is released
• ALPHA = implemented behind feature flag
• WORK REQUIRED = not currently implemented - requires work
• N/A = no changes required to client

In terms of implementation we were thinking to PR in new features as Alpha features, then once we think everything has been implemented we can open a final PR to move the features from Alpha and add Version2_14 to the client.

Does that all sound reasonable?

Thanks
@tedddyking and @Samze