Make OS_strnlen public

[jphickey]

Is your feature request related to a problem? Please describe.
The OS_strnlen() wrapper could be useful for apps, because strnlen is not a standardized function, but many times this behavior is needed/desired when reading fixed size string buffers.

An inline function exists in OSAL to provide a substitute but it is currently in an internal header.

Describe the solution you'd like
Move the function to the public header so apps can also use it.

Describe alternatives you've considered
Leave as is

Requester Info
Joseph Hickey, Vantage Systems, Inc.

[jphickey]

Unfortunately the "quick fix" to expose this and just move the header had some unintended consequences, due increased dependencies in the CFE PSP files that used "osapi-common.h" causing them to fail to build coverage tests.

Two options:

1. Forget about it and just have users who want this make their own wrapper to provide strnlen-like functionality
2. Fix PSP coverage test stubs so they work again (doable of course, but requires coordinated merge, makes this less trivial)

[jphickey]

OK - this actually breaks more than PSP, it affects sample_lib too. Basically anything that has stubbed out C libraries and/or string.h breaks due to the new dependency on memchr. It seemed simple but then reality got in the way....

The only way for OSAL to provide this in a practical sense and make it coverage-testable would be to make it non-inline - but that would have a negative performance impact, it would require stubs, all sorts of fallout.

My recommendation is to go with (1) - lets just leave it alone. Create your own local wrapper around memchr to get the equivalent function to strnlen where needed. Its simple enough that there isn't much lost in not having this consolidated to a single implementation.