Separate header files for message payloads and encapsulation

[jphickey]

Is your feature request related to a problem? Please describe.
This would be a continuation of the effort started in #2306 to better refine the contents of the header files used by CFE/CFS components.

Some stakeholders/users have a different encapsulation structure for the commands and telemetry. For this case, the message payloads stay the same, but a different wrapper structure is used, and may include a trailer as well as a (different) header.

The current naming scheme really only defines one file - the msgstruct.h file - that defines both payloads and encapsulation structures.

Describe the solution you'd like
Proposal is to further separate this, and put the payloads into a different header file than the encapsulation structures. Note that such a change would be transparent to current code so long as the historical msg.h file provides both.

In summary - the message payload content is tightly coupled to the component and the component source version, in that the expected fields must be in the message payload or else the software will not work. In contrast, the message encapsulation is very loosely coupled to the component implementation. Any dependencies in this area are abstracted already via the MSG API, so the component source is already insulated from these definitions.

Thus, the encapsulation can change pretty freely according to user preferences, whereas the payload content needs to match exactly what the C source expects. Therefore, it makes sense NOT to mix these in the same file, they should be separate files.

Additional context
Current practice is to "fork" a header file to provide the customization needed. Thus, a user may change the encapsulation structures - i.e. to use a different header or different trailer - by making a clone of the relevant file and modifying it.

In the case of encapsulation structs, the forked file contains both payload and encapsulation definition. This presents a problem if/when updating to a new version of a component, because the payloads may have changed. This means the file must be manually merged.

The process would be simpler if these were separate header files, because the payloads can be defined in one header that does not need to be cloned at all, whereas the encapsulation could be cloned and modified as usual. This would mean a smaller set of structures would need manual updating if/when migrating to a new version. In many cases, unless a message/command was added or removed, it would just work without any manual merge at all.

Requester Info
Joseph Hickey, Vantage Systems, Inc.

[jphickey]

Rather than introducing yet another header file, the easiest/simplest approach would be to keep the payload structs right where they are, but move the encapsulation structs back into the msg.h file (where they were initially, before #2306). In essence, this would be reverting just a bit of the original changeset.