Contribution description

According to ieee802154_radio_confirm_transmit docs, the parameter of
confirm_op for IEEE802154_HAL_OP_TRANSMIT is to be populated as an out
parameter -- but this implementation unconditionally left info
unpopulated. Thus, when run with LLVM, _fsm_state_tx_process_tx_done
looked into an uninitialized info and thus crashed into failing
assertions.

Note that the init was initialized NULL and later that init is checked for being NULL; now there's an actual non-NULL (or maybe non-NULL as the caller may well pass in NULL) writing access.

I checked the wrappers for the other _confirm_op operations, and they either pass in NULL as the argument, or pass in a boolean clear parameter that does get set, so it seems justified to only set info in this particular branch. (One might consider moving the info population step up right away, but it kind of makes sense there if one anticipates there might come to be more ops that use an info in the same way, and as things are the compiler should be free to make that enhancement on its own).

Testing procedure

• Run the gcoap example with an nrf52 device (I used microbit-v2) and TOOLCHAIN=llvm

Issues/PRs references

Closes: #17591