Add a Unity macro to assert on platform error code difference

[davidsaada]

Description

Current platform error codes, defined in mbed_error.h header file, consist of the error code along with other information such as the module ID. This means that if we have a test that checks for the error code, an unexpected result would show a very large (negative) number, requiring user parsing in order to understand the real error.
This PR adds TEST_ASSERT_EQUAL_ERROR_CODE and TEST_ASSERT_EQUAL_ERROR_CODE_MESSAGE macros, checking only the status code (lower part) of the full error code, showing the interesting part of the error in case of a mismatch.

Pull request type

[ ] Fix
[ ] Refactor
[ ] Target update
[x] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

[deepikabhavnani]

@SenRamakri - Please review

[deepikabhavnani]

Looks good to me 👍

[0xc0170]

@ARMmbed/mbed-os-test Please review

[NirSonnenschein]

@ARMmbed/mbed-os-test reminder: Please review

[mikisch81]

@ARMmbed/mbed-os-test another reminder: Please review

[cmonr]

/morph build

[SenRamakri]

Hi David, Instead of using the error mask directly can you please use the macro MBED_GET_ERROR_CODE() macro. The reason is depending on error type the error code is encoded differently(this is due to support for Posix errors). Using the macro makes the code more portable?

[davidsaada]

Fixed.

[cmonr]

/morph build

[mbed-ci]

Build : FAILURE

Build number : 3631
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/8646/

[cmonr]

@davidsaada Please take a look at the build failure. Looks like there's something wrong with the PR's implementation when it's compiled with IAR.

[davidsaada]

IAR build problem was bypassed by removing the include to "mbed_error.h". This should be OK, as the only change here was in a macro, which should be used by users of mbed errors anyway.
@SenRamakri The reason for this build problem lies within "mbed_error.h": This header file includes "mbed_retarget.h", which declares the fdopen function. Now, this conflicts with the one declared in the internal IAR libraries. Tried to fix it without success. I'm leaving this one to you as many PRs depend on this one and as the problem has nothing to do with the PR itself.
If you wish to reproduce this problem, you can add the include to "mbed_error.h" in "unity.h" and then run the command:

mbed test --compile -m ARCH_PRO -t IAR -DMBED_HEAP_STATS_ENABLED=1 -DMBED_STACK_STATS_ENABLED=1 -DMBED_TRAP_ERRORS_ENABLED=1 -DMBED_ALL_STATS_ENABLE -n FEATURES-STORAGE-NVSTORE-TESTS-NVSTORE-FUNCTIONALITY

[NirSonnenschein]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 3634
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/8646/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

[mbed-ci]

Exporter Build : SUCCESS

Build number : 3241
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/8646/

[mbed-ci]

Test : FAILURE

Build number : 3416
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/8646/3416

[cmonr]

Sporadic NRF52 RTC test issue.

Will retest when able.

[cmonr]

Info: This PR has now been bundled into a rollup PR (#8760).

The CI failures that this PR saw do not appear to be the fault of the PR. To save time in retesting this PR, along with other PRs that experienced similar issues, it has been bundled into a rollup PR.

If any more commits are made in this PR, this PR will remain open and have to go through CI on its own.

[cmonr]

Info: This PR has been re-bundled into a new rollup PR (#8763).

The previous rollup found an issue with a bundled PR after new devices were added into master. The PR needing work has been removed.

No further work is needed here, as once that PR is merged, this PR will also be closed and marked as merged.
If any more commits are made in this PR, this PR will remain open and have to go through CI on its own.