lr-wpan: Fixes PHY reaction after a TX during BUSY_RX

This MR is meant to fix an issue that has been in the lr-wpan PHY for a while.

This should solve #428 (closed) and possibly #505 (closed) but we would need confirmation from @roberthartung1 and @TorbenPetersen to be 100% sure as I do not know their specific use cases.

This MR should also fix the issue reported by @edalm on Zulip about GitLab CI's valgrind jobs as the element that caused (m_rxEvent.Cancel()) is now removed.

Issue Decription

Occasionally, a PHY issues an order to TX_ON while the PHY is already on BUSY_RX. In normal circumstances, this case will not occur because transmissions must be subjected to CSMA/CA so the device would simply wait until the reception is completed before attempting to transmit. However, in the case of some special frames with high priority like ACK and BEACONS, the PHY is ordered to transmit as soon as possible. This implies canceling even the reception of possible ongoing frames and changing its state to TX_ON (both ACK and Beacon frames are not subjected to CSMA/CA).

The initial solution was to cancel the reception event, but this caused the corruption of the channel because the PSD would not be correctly remove from the m_signal object in the PHY which handles all the ongoing signals in the channel (as reported by @roberthartung1 in #428 (closed)).

The solution now is more simple: allow the execution of LrWpanPhy::EndRx () (previously canceled by m_rxEvent.Cancel()) so the signals are correctly removed but stop EndRx from changing the PHY state because the PHY state is already being changed by the forced Transmission request.

This MR also includes some simple coding style changes in some parts and an improvement to the LrWpanMac::DequeueInd .