feat: upgrade version endpoint

[arnoweiss]

What this PR changes/adds

This PR changes the setup of the common versioning endpoint.

1. Restrict versioning-endpoint to HTTPS across bindings
   Even in a distant future when there may be different bindings for DSP messages, it is reasonable to expect that the well-known HTTPS endpoint will be queried for which endpoints are relevant. A consumer has to start somewhere and it cannot be assumed that the DSP-binding a Provider uses is necessarily known.
2. Add the auth and binding properties
   The auth property holds a string telling the Consumer how to authenticate to the Provider's DSP endpoints. This is necessary, especially if the catalog-endpoints are protected already. The binding property describes the DSP-protocol binding so the Consumer knows not just WHERE to ask but also HOW. This is relevant for forward-compatibility.

Why it does that

Currently, the endpoint is neither useful (Consumer is likely unaware of authentication method) nor future-proof (introducing a new binding would render it useless).

Further notes

I'd like at least two concurring reviews as this is a consequential change. Despite that, it's backward compatible because (1) there is no binding apart from HTTPS and (2) all newly introduced properties are optional.

Closes #112

Please be sure to take a look at the contributing guidelines and our etiquette for pull requests.

[arnoweiss]

• Make the profile object an array and rename to profiles
• Make the binding property mandatory
• Push the semantics of the path object down to the bindings level

[lgblaumeiser]

I appreciate the approach to provide more metadata. Actually, I miss one important mechanism that might be added here. So far, it is not possible to group multiple entries here to express that these entries are representing the same DSP service in different versions. That would be necessary to do proper version handling in case of multiple services managed by the same host.

[arnoweiss]

Are you thinking of something like a serviceId property?

[lgblaumeiser]

Yes, that sounds right, so multiple entries could have the same serviceId, indicating that they reference the same service, resp. will provide basically the same DataSets only with different versions.

[arnoweiss]

opened a separate issue for this: #146