misc: fastrpc: workaround DSP access issue

When the process waiting for the DSP is interrupted with a signal,
the so-called 'non-kernel' calls are also interrupted and therefore
return to the caller since they wait_interruptible on the callback.

Also, on calling device release, the DSP will callback in *sequence*
all those calls which it didnt complete due to them being
interrupted. And after those have been invoked, the DSP will send the
response to the release request.

It has been noticed that when the TEARDOWN request is interrupted and
then followed very closely by a RELEASE request, the DSP can stop
responding [1].

Adding a delay when calls have been interrupted seems to work around
this issue.

[1] either the DSP stops responding, or the endpoint stops working
since the driver does not receive any more callbacks on
fastrpc_rpmsg_callback