Libraries that depend on the CMSIS-RTOSv2 API should link against
`cmsis-rtos-api`. The user application's `CMakeLists.txt` is reponsible
for picking a concrete implementation (e.g. `cmsis-rtx`).

This is violated by `lwip-cmsis-sys` which directly links against either
`cmsis-rtx` or `freertos-cmsis-rtos` depending on which library exists.
Because the CMSIS_5 repository which provides `cmsis-rtos-api` also
provides `cmsis-rtx`, `cmsis-rtx` always exists and `lwip-cmsis-sys`
always links `cmsis-rtx` by mistake, even when the application selects
something else such as `threadx-cdi-port`. To fix this, link
`lwip-cmsis-sys` against only `cmsis-rtos-api` and not any specific
implementations.

The fix further uncovers another preexisting issue: CMake does not
guarantee the order `cmsis-rtx` (or another implementation) gets linked
relative to other libraries such as `lwip-cmsis-sys`, but GCC's linker
requires `cmsis-rtx` (for example) to appear *after* `lwip-cmsis-sys`
which is the dependency order of C symbols. To ensure the implementation
such as `cmsis-rtx` appears after libraries that use `cmsis-rtos-api`,
now we require the application's `CMakeLists.txt` to do

    target_link_libraries(cmsis-rtos-api PUBLIC <implementation>)

as the standard way to select an implementation. Documentation, examples
and tests have been updated to reflect this.

To verify that the correct implementation of `cmsis-rtos-api` is in
the final executable when we use `threadx-cdi-port`, add a test for
mixed usage of native ThreadX and CMSIS-RTOS APIs and link it against
`lwip-cmsis-sys` which previously incorrectly pulled in `cmsis-rtx`.
This test isn't expected to catch all bugs of this sort, but we added it
so that we had a failing test against which we could, in test-driven
development (TDD) style, write and verify the fix.

Signed-off-by: Lingkai Dong <lingkai.dong@arm.com>