Protect asynchronous burst calls from hanging

Burst execution is asynchronous at the HAL layer: the runtime sends a
request packet across one FMQ, then waits for the response to be
received on the result FMQ. However, if the driver crashes after the
request request has been made but before the result has been received,
the runtime will hang. Specifically, the call to
ResultChannelReceiver::getPacketBlocking will never return.

This CL adds a death recipient to detect when the driver has crashed and
to unblock the runtime by returning a failure. The death recipient
additionally marks the sender and receiver objects as invalid, causing
any subsequent calls to send or receive a packet to immediately return a
failure in order to avoid future hangs.

This CL additionally returns a value to the runtime to indicate whether
the burst execution should be re-run using another execution path, such
as IPreparedModel::executeSynchronously* or IPreparedModel::execute.
ExecutionBurstController will request a re-run either when (1) the
request packet failed to send across the FMQ (e.g., when the number of
elements in the packet exceeded the size of the FMQ) or (2) when the
burst object has been marked as invalid.

Test: mma
Test: ran NeuralNetworksTest_static, made the sample driver's burst
      execution artificially long, killed the sample driver, and
      confirmed (1) the runtime recovered and (2) the appropriate log
      messages appeared in logcat
Bug: 129157135
Bug: 131086786

Change-Id: I04fcb6247dc78ea057c7596682159af1f9025235