This changes the implementation to be solely build upon `endian.h`
and `unaligned.h`.
This turns `byteorder.h` basically in syntactic sugar on top of the
`<endian.h>` API, reducing the complexity of the implementation and,
hence, the maintenance effort.
Note that yields a small ROM reduction as well *yeah!*
```
make BOARD=nrf52840dk RIOT_CI_BUILD=1 BUILD_IN_DOCKER=1 -C tests/unittests
```
Yields before this commit:
```
text data bss dec hex filename
417788 2200 28640 448628 6d874 /data/riotbuild/riotbase/tests/unittests/bin/nrf52840dk/tests_unittests.elf
```
And with this commit:
```
text data bss dec hex filename
417756 2200 28640 448596 6d854 /data/riotbuild/riotbase/tests/unittests/bin/nrf52840dk/tests_unittests.elf
```
RIOT supports two distinct families of the MSP430: The [MSP430 x1xx]
MCU family and the [MSP430 F2xx/G2xx] MCU family. For both incompatible
MCU families the code was located in the msp430fxyz folder, resulting
in case of the UART driver in particularly bizarre code looking roughly
like this:
#ifndef UART_USE_USCI
/* implementation of x1xx peripheral ... */
#else
/* implementation of F2xx/G2xx peripheral ... */
#endif
/* zero shared code between both variants */
This splits the peripheral drivers for USCI and USART serial IP blocks
into separate files and relocates everything in cpu/msp430, similar to
how cpu/stm32 is organized.
[MSP430 x1xx]: https://www.ti.com/lit/ug/slau049f/slau049f.pdf
[MSP430 F2xx/G2xx]: https://www.ti.com/lit/ug/slau144k/slau144k.pdf
This drops special handling for Mac OS (X) `native`, which is not
supported anymore anyway and causing issues when building for
non-`native` targets on Mac OS.
