Introduce new versioning policy to maintain client backward compatibility

[r4victor]

dstack uses semantic versioning for the package. It guarantees server backward compatibility within the same minor version (e.g. 0.18.x) (with some caveats), but no client compatibility is guaranteed. Moreover, new clients are declared to be always incompatible with older servers.

The current approach is reasonably good for maintaining server backward compatibility but it prevents any client backward compatibility. At least, we would like to be able to make releases preserving client backward compatibility when there are no new features introduced, e.g. client bug fixes.

Proposal

• Full client backward compatibility is maintained within minor releases, e.g. 0.18.x. If there is a breaking change, i.e. the new client does not work with old servers, introduce a new minor release 0.18.14 -> 0.19.0.
• Full server backward compatibility is maintained within minor releases. Partial server backward compatibility is maintained across minor releases. Breaking changes may be introduced but they are minimized and always preceded by deprecation warnings. So if a feature/field is to be removed, it’s first marked for deprecation for several minor releases, and only then can be removed.
• Release notes always have Deprecations and Breaking changes sections if there are any.

Benefits

• dstack can have releases preserving client backward compatibility. Users are not forced to update clients when the server is updated.
• dstack maintains server backward compatibility but has flexibility to remove some functionality to reduce maintenance costs.
• Users are informed about whether the release can break something.