Contribution description

This tests makes little sense to have for a number of reasons:

1. One should not use iprintf() for a number of reasons:
   1. It is non-standard and using it over printf() makes the code less portable (e.g. it cannot be used on AVR)
   2. The idea of adding a leaner variant of printf() in addition to the larger one is bogus, as apps will end up using both resulting in a larger firmware instead of a smaller
   3. RIOT's build system already has the printf_float module to control whether formatting of floating point numbers should be suppered. This mechanism will actually result in smaller builds, if floating point support is not needed, as it prevents two variants of printf to be linked in.
2. The test checks some implementation details (e.g. whether the address of two functions is identical), rather than correct behavior of the implementation. This is completely bogus.

Testing procedure

Happy CI

Issues/PRs references

#9599 introduced this test.

As can be seen in the PR, the point of the test is to check whether using nano.specs from newlib via the module newlib_nano has the intended effect. But since it is up to whoever is building / packaging newlib to decide whether to provide a nano.specs at all and how the nano.specs variant is configured, this way of testing does not appear to be super valid.