Improve service-info to enable service discovery

[jaeddy]

The Discovery Networks team is developing a specification to register and discover API services (e.g., across GA4GH); see slides from 2018-12-10 Cloud Work Stream call for background:
https://docs.google.com/presentation/d/1-TFvBdIYaxm-MpR7WBL8U5eqHa2Po2DuDyu7HBfjVyY/edit

We should try to coordinate with @mcupak and @andrewyatz (as well as DRS, TRS, and TES teams) to refine service-info endpoint attributes, information.

Topics on which to normalize:

• version (of API specification, of actual node/implementation)
• access/authorization description
• service identification (ID, service type, aliases)
• status (health, development)
• provenance/history (creation, updates, maintainers, etc.)

We should also be able to help identify what might be "core" versus "service-specific" attributes — starting with what works across GA4GH Cloud APIs, then thinking about how to generalize to other services.

Best starting point might be a PR with a straw man updated schema for service-info to get feedback.. cc: @briandoconnor, @dglazer, @cricketsloan — who else should we make sure to include in discussions?

2020-01-28 Update:

• Update OAPI version to 3 - Bump OAPI 2 to OAPI3 (Autogenerated) #143
• Merge WES Service-Info dict with GA4GH Service-info - Implementing GA4GH Service-Info for WES #144

[jaeddy]

Should take a look and incorporate some of the suggestions from #122

[susheel]

Update: ga4gh-discovery/ga4gh-service-info#how-to-use-and-extend-this-specification

The suggestion in workstream call is to create a PR but leave it pending discussion of loose ends

[andrewyatz]

Seems like a good idea. We've tried one true extension in refget but I would like to see how this works as we spin it out to other standards and a PR seems the best way to do this