tests/drivers uart_pm: Fix for too fast targets

On the async configurations, the first part of the test
(test_uart_pm_in_idle) can interfere with the second part
of the test, if the device has a fast enough CPU.
This is due to the first part of the test ending
as soon as it queues the last byte for transmission.
If the device is fast enough (and the simulated
nrf52 is), the 2nd part of the test will start executing
enabling the UART Rx, which can result in either
the Rx being enabled mid frame, which can result in a frame
error or even before the Tx HW started pushing the byte
in the line (resulting in that byte being received).
Neither of these cases are handled by the 2nd test,
which sees a spurious error or received byte
and fails.

Let's just add a small delay at the end of the first test
to allow the Tx of the last byte to be done.

Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>