Bluetooth: Controller: Fix CTE_REQ disable lock if there is no CTE_RSP

The periodic CTE_REQ disable command, requested by Host, may be locked
until connection is dropped due to missing CTE_RSP from peer device.
That is caused by implementation of CTE_REQ disable and CTE_REQ
control procedure handling.

The procedure is marked as active when CTE request was send to peer
device. It is marked as inactive after completion of the procedure.
That caused locking of CTE disable on a semaphore.

The BT 5.3 Core Spec, Vol 4, Part E, section 7.8.85 says the HCI_LE_-
Connection_CTE_Request_Enable should be considered active on a conne-
ction from when Host successfully issues the command with Enable=0x1
until a command is issued with Enable=0x0 or single LLCP CTE request
has finished (CTE_Request_Interval=0x0). Also there is a clarification
from BT SIG that the command with Enable=0x0 does not affect any
initiated LLCP CTE request. That means Controller is allowed to finish
already started procedure and it is not allowed to start new LLCP CTE
request procedure after completion of the command with Enable=0x0.

Taking that into account, there is no need to synchronize ULL and LLL
in regard of disable the LLCP CTE request while the procedure is
pending. Controller is free to complete the procedure or terminate it.

The change removes all code related with cte_req.is_active, disable
callback and waiting of ULL for LLL to finish the LLCP CTE request.

The ULL will complete the HCI_LE_Connection_Request_Enable with
Enable=0x0 immediately. In case the procedure is disabled in before
the response arrives, then further processing of the response is
dropped and the procedure context released.

The context is not released by the code responsible for disable
handling, to have single place where it is done.

Signed-off-by: Piotr Pryga <piotr.pryga@nordicsemi.no>