Fix #1449, POSIX implementation honors stack pointer

[jphickey]

Checklist (Please check before submitting)

• I reviewed the Contributing Guide.
• I signed and emailed the appropriate Contributor License Agreement to GSFC-SoftwareRelease@mail.nasa.gov and copied cfs-program@lists.nasa.gov.

Describe the contribution
When the OS_TaskCreate() function is called with a non-NULL stack pointer, the POSIX implementation now should use this pointer as intended. Previously it was always allocating a new stack buffer, ignoring the passed-in pointer.

NOTE: When using this feature, the caller must use caution to make sure the buffer being passed in is large enough to use as a task stack. Particularly when running under a desktop Linux/Glibc environment, the infrastructure puts a considerably large object on the stack. For example, in the osal-core-tests, the stack size was too small.

Fixes #1449

Testing performed
Build and run all tests. Added tests that ensure the stack pointer is being honored as expected.

Expected behavior changes
User-supplied stack buffer will be used on POSIX.

System(s) tested on
Debian

Additional context
This could have negative consequences if the user was assuming RTOS-like behavior (e.g. no thread local storage) and was using very small stack sizes. If the supplied stack size is less than 16k, (or PTHREAD_STACK_MIN) then the call will now fail, whereas previously it would quietly be made bigger than requested.

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

[jphickey]

Ready for [re-]review. Checking further into detail of the RTEMS implementation -- the needed API was only added in the latest development branch (6.x) and is not available on either RTEMS 4.11 nor 5.x. Furthermore, the documentation warns that this is only intended for use with low-level device drivers that have special requirements, and general tasks should not force a stack pointer, as the stack buffers have special requirements for size and alignment.

Therefore, with the consideration that we will likely also deprecate/discourage users from specifying a stack buffer due to similar issues on other platforms, the best solution for now is to simply skip this functional test on RTEMS.