Fix #1170, refactor target config objects

[jphickey]

Describe the contribution
Rework the dynamic content so it is generated entirely via a CMake "configure_file()" command into a C source file (.c) that
can be built as normal.

This removes the need for inline #include statements to pull in data fragments to fill in the data.

Fixes #1170
Fixes #352

Testing performed
Build and run all unit tests, sanity test CFE, confirm versions reported as expected.

Expected behavior changes
This reports multiple event "91" (version info) - one event for each statically linked code module. This now also includes supplemental modules such as "msg" and "sbr" (these were not reported at all before).

This also moves reporting of the "mission config" name from event 91 to event 92 (build info) as it is not really version info. Ideally event 91 should be strictly for source control revision info. Any other environment/config info should be in the other events.

System(s) tested on
Ubuntu 20.04

Additional context
This also attempts to better differentiate/clarify the two different versions that are reported.

The first version is administratively-assigned, traditional "semantic" version (major/minor/rev plus dev build number). This is updated manually and it is what is reported in CFE event 2 during start up as follows:

EVS Port1 66/1/CFE_ES 2: cFS Versions: cfe v6.8.0-rc1+dev348, osal v5.1.0-rc1+dev262, psp v1.5.0-rc158. cFE chksm 65346

The second version is the automatically-obtained "source" version which is gained by introspection of the source code at compile time. This is reported in CFE event 91, as follows:

EVS Port1 66/1/CFE_ES 91: Version Info: Component cfe-core, version git:v6.8.0-rc2-346-g3aa80ed0
EVS Port1 66/1/CFE_ES 91: Version Info: Component osal, version git:v6.0.0-rc1-1-g7576fed6
EVS Port1 66/1/CFE_ES 91: Version Info: Component psp, version git:v1.5.0-rc1-61-gf3dae6c-dirty
EVS Port1 66/1/CFE_ES 91: Version Info: Component msg, version git:v6.8.0-rc2-346-g3aa80ed0
EVS Port1 66/1/CFE_ES 91: Version Info: Component sbr, version git:v6.8.0-rc2-346-g3aa80ed0
EVS Port1 66/1/CFE_ES 91: Version Info: Component resourceid, version git:v6.8.0-rc2-346-g3aa80ed0

Important to note that instead of squeezing this all into a single event 91 as had been done before, this sends a separate event for each component. This means that all components can be done (note this includes msg/sbr/resourceid now, these were not reported before) as well as making it possible to split "cfe-core" into its components as well. It will scale more easily to any number of modular components.

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

[jphickey]

Created as a draft because this still needs a few unit test updates to get full coverage on the modifications, but before I do that I wanted to get some other eyes on it to make sure the general concept is good to go.

[jphickey]

Also worth a note - there was previous concern as to being potentially too tightly coupled with "git" for the version control info. In this change I have also isolated the version control actions to a separate script (generate_git_module_version.cmake) and also added the capability for a user to provide their own script that does this - so they can call some other tool like SVN or adapt to however they like to do branching/tagging so it provides a useful result. But the default one works fine for the git submodule-based bundle out of the box.

[jphickey]

Rebased to "main" ... but will still hold this one as draft until consensus is reached in nasa/cFS#200 since this will also affected by that decision.

[skliper]

@astrogeco I'm fine with fast-tracking this one if it helps... or review the WIP from Joe as long as we can get the WIP closed out and merged next cycle.

[astrogeco]

CCB 2021-03-03 APPROVED

• Using a .c file to avoid developers including a header in different places since these defines are meant to be used in a very specific way.
• Splits version.cmake into two files generate_build_env.cmake and generate_git_module_version.cmake to accommodate implementations that DO NOT use git
• Need to better document the customization approach
• Need to have a separate documentation for the build system (See Document the cmake build system #760)
• We should start moving away from generating cmake c flags the CORRECT way to do it is to use the target specific files
  • Maybe have example to help people