Provide consistent versioning for Nanover protocol.

Proposed versioning is as follows:

- ..

The patch_version is for small bug fixes and features that have no impact with respect to API compatibility. Thus clients of a given major/minor version should be able to pick up new patch versions and expect existing functionality to work in a compatible way. Patch_version may be implemented as the number of commits to the Nanover_protocol main branch since the last minor version or as a UTC date-time stamp of the corresponding CI build on main .

Minor versions represent a significant upgrade to the protocol (with respect to number of issues fixed, new features etc.) still maintaining backwards compatibility for clients using earlier minor versions (within the same major version). So clients using, for example, Nanover-protocol version 1.2.x should be able to upgrade to version 1.3.y and expect API compatibility.

Major versions represent a significant upgrade to the protocol and may break API compatibility (for example by removing APIs that were deprecated in earlier major versions). Within a major version, APIs may be deprecated but still supported until the next major version.

Thus a client upgrading from, for example, version 1.3.x to version 2.0.y may experience API incompatibility will be documented (either as deprecation warnings in the earlier version) or in the upgrade documentation for version 2.0.

In general clients should be able to upgrade to any minor version within a major version (without upgrading to intermediate minor versions) without breaking API compatibility.

No files, tests, or entry points are named. Start by locating where the Nanover protocol version is defined and how clients consume it, then determine the implementation and compatibility checks needed to apply the proposed major, minor, and patch scheme.

Written by the indexing model from the issue text.