Follow up to discussion in nasa/osal#824 and in CCB:2021-02-24

Here's my view of the situation so far.

Problem:

1. Developers and users need to know what "version" they're running.
2. Developers and users need to know what the "latest stable" version was
3. We are aiming to conform to semantic versioning which assigns meaning for the first three numbers in a version.
4. There are multiple places and mechanisms to get the "version state":

• HK Telemetry
• Plain Text source files
• EVS Response to NoOp
• EVS Message upon startup

5. The current "full version state" is in the form of MAJOR.MINOR.PATCH+devBUILDNUM

Each of these mechanisms should "report" a minimal set of non-contradictory, self-evident information.

Solution approaches for reporting the version state during development

These are not mutually exclusive, I foresee landing in some sort of combination between them.

1. Keep the REVISION number to 99
2. Make the MISSION_REV number 99
3. Make all numbers the same value ie. 99.99.99.99 or 0.0.0.0
4. Add full version string to HK telemetry
5. Add a hash or checksum to HK telemetry that encodes the version information contained in the
6. Educate and document the version numbering
7. Use a git-based approach
8. Remove version reporting from HK Telem

Constraints

1. HK Telem should be kept small given that it is sent regularly
2. "99" indicator for development has been accepted practice internally and in other software (see RTEMS Version numbering )