Bluetooth: ECC: Fix command status emission from wrong thread

HCI drivers are obliged to send HCI Command Status/Complete events
from a separate context than all other data, however the ECC wrapper
was violating this rule (sending everything from the same ECC thread).
This could lead to a deadlock if e.g. the ECC API user decides to
generate a DHKey from the same callback that it got notified of local
key-pair generation.

The obvious solution is to emit the Command Status directly from the
send function, before passing the command to be processed by the ECC
therad (through a k_fifo). However, this is not quite so simple since
bt_buf_get_cmd_complete() reuses the original command buffer, meaning
we'd loose the original parameters after sending a Command Status.

To work around this limitation with bt_buf_get_cmd_complete() we stop
passing the command buffer to the thread and instead store the
parameters in static variables and do the thread communication using
flags and a semaphore. One side effect is that only one command can be
pending at a time, however that works out fine for all of the users of
ECC.

A nice side effect of moving some things to static variables is that
we end up reducing call stack usage in the ECC thread, allowing it to
be shrunk by 180 bytes (verified to be sufficient for both ARM and
x86 boards).

Change-Id: Ic41f0316d3fe4d14b64fd3d0a549b221d168411a
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>