Fix #285, Refactor OSAL code selection

[jphickey]

Describe the contribution
Use separate source files and CMake-based source selection based on feature configuration, rather than using the C preprocessor for including/excluding different OSAL function groups.

Refactor all implementation units to provide a separate header file for each functional group/subsystem. Remove "static" declaration on internal helper functions so they can be invoked from unit test.

Fix #285 (primary)
Also Fix #214 and fix #195 (trivial fixes rolled in as part of refactoring) and fix #432 (separate commit)

Testing performed
Build and execute CFE for VxWorks, POSIX and RTEMS. Sanity check of CFE functions. Confirm all unit tests passing and coverage test of VxWorks is working (lcov shows 100% for covered modules).

Expected behavior changes
No impact to runtime code. Changes build system considerably, however.

• No more user-maintained osconfig.h file - now replaced by a cmake configuration file
• Break up low level implementation into small, separate subsystem units, with a separate header file for each one.

System(s) tested on
Ubuntu 18.04 LTS 64 bit (build host, native test)
i686-rtems4.11 cross build using QEMU
ppc-vxworks6.9 cross build using MCP750

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

[jphickey]

Force-push to rebase onto latest "master" branch rather than integration-candidate, now showing as one commit...

[jphickey]

Force pushed to squash all fixes so far. Tested on MCP750 and looks good there too. This is ready for CCB review.

[skliper]

20200422 CCB - Covered concepts and patterns, line-by-line and official approval will be off-line. Note will require rebases and careful merge to avoid conflicts.

[jphickey]

Question - Just added enhancement #434 for the separate issue, which made me think rather than adding a separate config option for every debug feature, maybe we should also rename OSAL_CONFIG_DEBUG_PERMISSIVE_MODE to be simply OSAL_CONFIG_DEBUG_MODE so that other debug-related items could be grouped with it rather than making a new option for each debug feature. I can foresee having other debug niceties be added in the future.

As this PR is already changing these configs, maybe it should preemptively rename this one and extend its scope to be applicable to these other debug features, or is it preferable to have more fine-grained options?

[skliper]

I prefer to continue to support custom configuration of the individual options, but have no problem with a general "wrapper" switch to enable them all.

[astrogeco]

@skliper based on your email I added the fast track label, do you want to put this in the 20200415 IC? I'll probably merge that to master by Monday April 27

[jphickey]

I don't think we can do that due to cross dependencies. There were already other items in the 2020-04-22 CCB which introduced changes that need to be reconciled/merged with this change set.

I recommend to follow the normal cycle, just do so as expediently as we can.

[astrogeco]

@jphickey merged everything else, might need to work with @skliper and @dmknutsen on #423 and #421

[jphickey]

FYI - rebased to the 2020-04-15 baseline. Had to change the base branch back to master too (as it is!).

[astrogeco]

Merged in 7a7e6d1