Fix #1336, function block comments

[jphickey]

Describe the contribution
Fixes #1336

Scrub all internal APIs within CFE core to make comment blocks in sources and headers more consistent.

Whenever a function is prototyped in a header, this moves the information about the function behavior to that prototype and puts it into doxygen format. The comment block on the function implementation refers the reader to the prototype - it does not duplicate the info. Exception for local helper functions which are not separately prototyped, these may have pre/post condition info in the block itself.

All functions definitions are noted whether they intend to conform to the public API (i.e. from a header in core_api) and therefore have global scope, or if they have application-internal scope, or if they have file/local scope.

Testing performed
Build and sanity check CFE, run all unit tests

Expected behavior changes
None - documentation updates only

System(s) tested on
Ubuntu 20.04

Additional context
Changes to each subsystem are put in a separate commit.

Contributor Info - All information REQUIRED for consideration of pull request
Joseph Hickey, Vantage Systems, Inc.

EDIT - also fixes #1350 (deletes instead of moves, they are not implemented)

[jphickey]

Note that in cases where this moved comment info/notes/documentation from the definition to the declaration, it also converted it into doxygen markup where possible. This takes the first step at putting some doxygen information on every internal API, not just public APIs. However it does not (yet) fully document all parameters and outputs/return values. This may show up in the doxygen warnings. (it was never documented, but now it might be noticed by the tools because it was converted to doxygen style markup).

[skliper]

Only nit/recommendation would be not to explicitly reference the header file name the API is defined in. I'd just put "see header file for full documentation" or similar. These move around (and will move again when refactored), so easier to keep generic and explicit reference doesn't really provide that much benefit (not worth the effort to keep up-to-date).

[astrogeco]

CCB:2021-04-21 APPROVED

• all comments, some hand edits to docs
• Is there a way to "tell at a glance" what corresponds to public APIs? -> Yes, the file naming pattern and where the header file lives
• Missing some parameters but we will add those in a separate issue

[jphickey]

Only nit/recommendation would be not to explicitly reference the header file name the API is defined in. I'd just put "see header file for full documentation" or similar. These move around (and will move again when refactored), so easier to keep generic and explicit reference doesn't really provide that much benefit (not worth the effort to keep up-to-date).

See commit a3b8e80 which replaces this to just say "See description in header file ..."

[jphickey]

Rebased to latest "main" branch to resolve conflicts.