Document/implement naming pattern for created elements

[skliper]

Is your feature request related to a problem? Please describe.
Inconsistent on namespacing of created elements (see #1401).

Describe the solution you'd like
Scrub "names" of created elements and how they are defined (configurable, #define, locally) and document/implement a common pattern. Really don't need to be configurable, if only used once they don't really need to be a separate define (only required when ID is not available and need to be looked up which is rare sharing case), some prefix with CFE, etc.

Describe alternatives you've considered
None

Additional context
Code review

Requester Info
Jacob Hageman - NASA/GSFC

[jphickey]

As noted in #1401 (comment) there is a definite advantage to qualifying internal resource names with the owning app, as it helps avoid collisions.

The key thing that needs to be documented, if we are to do this, is to make it clear that the name passed into the initial "create" API (whatever resource type it is) might not match the final assigned/fully-qualified name. One needs to create the resource, get the ID back, then call the "Get Name" on that ID to get the fully-qualified/real resource name. Programmers should not assume that the name they pass to the initial create call will be the final/complete name of that resource, that's all.

We should have a separate "Get Name" function for every resource type, so this shouldn't be an issue.

[jphickey]

I would also recommend that whatever pattern is settled upon for namespaces/qualifiers of resource names should also be applied to other internal resources, such as Semaphores/Mutexes/Queues that the core apps create, to make everything consistent in this regard.