Fix #95, Update command handler function message pointers and return

[thnkslprpt]

Checklist

• I reviewed the Contributing Guide.
• I signed and emailed the appropriate Contributor License Agreement to GSFC-SoftwareRelease@mail.nasa.gov and copied cfs-program@lists.nasa.gov.

Describe the contribution

• Fixes Use CFE pattern for command handler functions #95
  • Updated the command handler functions to use their specific command message types (FM_NoopCmd_t, FM_ResetCountersCmd_t etc.) rather than the generic CFE_SB_Buffer_t.
  • Converted return types of the command handler functions and other relevant functions to CFE_Status_t (also changed their status/result variables to CFE_Status_t)
  • Added a general error return code FM_ERROR
  • Used some of the new, more specific, CFE error return types:
    • Converted the previous false returns from failures during FM_IsValidCmdPktLength() in the dispatch routines to the new CFE return code CFE_STATUS_VALIDATION_FAILURE
    • CFE_STATUS_INCORRECT_STATE and CFE_STATUS_RANGE_ERROR in suitable locations instead of just using FM_ERROR

Question: Does something need to be done in terms of deprecation due to the change to the API (the FM_SendHkCmd() BufPtr parameter type has changed)?

Testing performed
GitHub CI actions (incl. Build and Run, Unit Tests etc.) all passing successfully.

Expected behavior changes
Behavior largely unchanged.
Compiler error is now thrown if the command handler functions are invoked with any type other than their own specific command type.
Using a defined set of error return macros and the CFE_Status_t return type improves code clarity and makes FM more consistent with cFE and the other cFS apps.

Contributor Info
Avi Weiss @thnkslprpt

[github-advanced-security]

CodeQL found more than 10 potential problems in the proposed changes. Check the Files changed tab for more details.