qcacmn: lock reo_cmd_lock earlier in dp_reo_send_cmd to avoid race cond

In dp_reo_send_cmd(), when adding callback info to reo_cmd_list, we lock
and unlock reo_cmd_lock just before and just after adding the info to
the reo_cmd_list tailq.

The functions that dp_reo_send_cmd() call ends access to
reo_cmd_ring before dp_reo_send_cmd() adds the callback info to
reo_cmd_list. As such, there is a period of time where
dp_reo_status_ring_handler() can end up processing the REO device's
response from reo_status_ring and iterating through reo_cmd_list, all
before dp_reo_send_cmd() can get a chance to add the callback info to
reo_cmd_list.

Since dp_reo_status_ring_handler() also acquires a lock on reo_cmd_lock
before iterating through reo_cmd_list, we can instead have
dp_reo_send_cmd() lock reo_cmd_lock before even writing the cmd to
reo_cmd_ring. That way, if dp_reo_status_ring_handler() manages to
process the REO device's response before dp_reo_send_cmd() can add the
callback info, then dp_reo_status_ring_handler() will be blocked from
iterating through reo_cmd_list due to the lock on reo_cmd_lock.

Co-authored-by: Andrea <andrea@cpushare.com>
Change-Id: I955fd333631311e88ba701c0154c704def3d8ea9