Rename files, functions, and variables to match APPNAME_* pattern

[astrogeco]

Describe the bug
PR #73 shed light on inconsistencies in naming conventions. There are multiple items named SAMPLE_itemname as opposed to SAMPLE_APP_itemname.

To Reproduce
One relevant example is SAMPLE_TblValidationFunc in sample_app.c:226

Expected behavior
All item names should use the prefix SAMPLE_APP as opposed to SAMPLE. In the example above the correct name should then be SAMPLE_APP_TblValidationFunc.

System observed on:
Source Code

Reporter Info
Gerardo E. Cruz-Ortiz, NASA-GSFC

[jphickey]

I would also like to suggest that as part of renaming any files - also check that they reside in the appropriate directory.

In particular - the sample_app_msg.h, sample_app_events.h, and sample_app_table.h should reside in the mission_inc directory as these are mission-scope definitions that other entities must use or reference - namely the ground system. These really shouldn't be stuck in the src directory which should only be used for private, internal-use header files.

As far as I can tell, the only header file in the src directory that actually belongs there is sample_app_version.h.

[astrogeco]

Agreed, also whenever we implement this we should use the git mv command

[jphickey]

I mention it because at least one user ran into trouble and emailed me because they ran into trouble when including the message definitions from their app's "src" directory externally in other apps - when I pointed out that external/public API like message defintions should be in a separate "inc" directory - turns out the only reason they had it in src was because that's where sample_app had it.

So I really think its worth the investment to fix all the naming/file/directory patterns and make sure they really are the model we want users to adhere to. Including for the upcoming bundle release associated with cfe 6.8.

[jphickey]

Actually running into issues due to this name inconsistency - probably worth fixing this....