Potentially blocking call within critical section

In the following controller code:

https://github.com/apache/mynewt-nimble/blob/7b14eab3d07caffa3a70046271b9f5b805f5c965/nimble/controller/src/ble_ll_rfmgmt.c#L285-L300

`ble_ll_event_add` is called while inside a critical section. This calls:

https://github.com/apache/mynewt-nimble/blob/7b14eab3d07caffa3a70046271b9f5b805f5c965/nimble/controller/src/ble_ll.c#L1426-L1430

In case of FreeRTOS,

https://github.com/apache/mynewt-nimble/blob/7b14eab3d07caffa3a70046271b9f5b805f5c965/porting/npl/freertos/include/nimble/nimble_npl_os.h#L100-L104

https://github.com/apache/mynewt-nimble/blob/7b14eab3d07caffa3a70046271b9f5b805f5c965/porting/npl/freertos/src/npl_os_freertos.c#L60-L80

As you can see above, `xQueueSendToBack` is called with `portMAX_DELAY`. I guess at the very least, we should add a zero delay if we're within a critical section. Also, see https://forums.freertos.org/t/critical-sections-freertos-api-calls/17352.

Start in nimble/controller/src/ble_ll_rfmgmt.c and trace ble_ll_event_add through nimble/controller/src/ble_ll.c into the FreeRTOS NPL files porting/npl/freertos/include/nimble/nimble_npl_os.h and porting/npl/freertos/src/npl_os_freertos.c. Confirm the blocking xQueueSendToBack path while the critical section is held and define behavior that cannot block there. Done means event scheduling remains correct and the FreeRTOS critical-section path is validated.

Written by the indexing model from the issue text.