do not get bridged channel for HOLD/UNHOLD events

This fix the original deadlock, since we are not locking anymore the
bridged channel while we have the lock on chan (obtained in __ast_read).

In our case, we don't need to know the bridged channel for these events.
call ast_cel_report_event after unlocking the channel

ast_cel_report_event should not be called with the channel locked. That
said, in __ast_read, ast_cel_report_event is already called (upstream
code) with the channel locked, so in practice that is fine in some case.
That said, we want to be on the safe side, so for the HOLD/UNHOLD event,
we call ast_cel_report_event only after unlocking the channel.

__ast_read is not called with the channel locked, so the channel is
really not locked (i.e. the recursive feature of mutex is not used here)
after the call to ast_channel_unlock.
Merge remote-tracking branch 'origin/5298-fix-cel-event-hold-deadlock'