Design and implement proper way of managing CMAPI versions and URLs

CMAPI is a published REST API. As is the case with all such software, there comes a point when a sufficiently radical change is being made to the API, such that would make invocation by older programs unsafe.

Standard practice in case of REST is to shift the URL of the newer version, while leaving the prior one reference intact.

In the course of producing release 5.6.1 with CMAPI 1.4, an MCOL 4541 was deemed sufficiently risky to warrant the API change. Unfortunately, this was done a t a late stage and has not been coordinated with downstream dependents.

As such, in 5.6.1 the API change has been reverted back to what it was before (/cmapi/0.4.0). This ticket is about designing the sustainable method for managing disruptive changes to CMAPI.

In accordance with good practices, the design of the solution will be done using a more or less formal design spec, shared for editing and commenting with all the stakeholders.

https://docs.google.com/document/d/1r_ZqQkayXcbk9SP2JxLTXLsBT8ezZpTgM_9dW-_WDQg/edit#