More test failures related to "chmod" implementation

[jphickey]

Describe the bug
The current OS_FileChmod_Impl on POSIX has some issues/limitations:

1. A while back this was changed from using the filename based calls to using a file descriptor, which "protects" against a theoretical issue where the file may get renamed while the operation is in progress. However this introduced a potential for a file descriptor leak -- If the fstat() call fails, the OS_ERROR is returned, but the file descriptor is left open.
2. Any failure is reported as the generic OS_ERROR ... This should do a better job of translating the errno to a more specific error code. In particular, not all file systems support unix-style file permissions - such as the very common FAT32/DOSFS - and in this case the fchmod() call is likely to return -1 with errno set to something like ENOTSUP or ENOSYS.
3. Also a file system can be mounted read only, which also prevents chmod() from working.

The main issue of 2+3 above is that the generic OS_ERROR code causes the chmod unit test to fail.

To Reproduce
Run the chmod test on VxWorks using a DOSFS mounted filesystem (e.g. CF:0 on the MCP750 test platform).

Expected behavior
The chmod test cases should be skipped without failing the overall test in cases where the mounted file system does not support/allow permission to be changed.

System observed on:
VxWorks 6.9 on MCP750

Additional context
So this is just a matter of translating the errno values for these conditions into OS_ERR_NOT_IMPLEMENTED instead of OS_ERROR, because the test is already implemented to check for and skip the rest of the test when it gets this return code.

Reporter Info
Joseph Hickey, Vantage Systems, Inc.