Error code documentation updates related to enforcement/test

[skliper]

Is your feature request related to a problem? Please describe.
See #331 for related issue/discussion.
Lacking documented approach for return code checking across functional tests.

Describe the solution you'd like

1. Update the error code list in API documentation to state:
   The specific error code definitions may be extended or refined in future versions of the software. Users should avoid unique error code handling except where required and documented explicitly in the API. Typical implementations should just check for OS_SUCCESS or report the error.
2. Typical return code documentation (for just execution status):
   \return Execution status. Success and error codes below are verified by test, but users should not assume the error code list is exhaustive. Precedence is not defined/enforced, calls with multiple errors may return any one of the related the error codes.
3. Scrub API error code documentation with the concept functional tests will verify the error codes explicitly defined, should just be a general set (not implementation unique).

Describe alternatives you've considered
See discussion in #331

Additional context
Coverage tests are expected to verify every implemented return code (white box). Functional tests are API based.

Requester Info
Jacob Hageman - NASA/GSFC

[skliper]

Also touched on in OSAL code review in relation to OS_HeapGetInfo