Prevent hang for asynchronous calls when transport failure occurs

Prior to this CL, asynchronous calls were protected with the following
usage pattern:
(1) the callback object is registered for protection
(2) the asynchronous call that uses the callback object is invoked
(3) callback->wait() is called to wait for the asynchronous results
(4) the error status of launching the call is checked
(5) the callback object is unregistered for protection when leaving
    scope

However, if a transport error occured when launching the asynchronous
execution (e.g., the data being sent across HIDL exceeds a preset
limit, resulting in a transport error), the code will continue waiting
at (3) before it can check the launch error in (4).

This CL fixes this by checking the launch status before waiting for the
results. Additionally, because VersionedIPreparedModel::execute takes in
a callback as an argument from the caller, extra protections are put in
place to notify the callback in the event that the asynchronous call
could not be launched because of unexpected behavior from the driver or
internal problems in the runtime.

Bug: 133325508
Bug: 118624080
Test: mma
Test: NeuralNetworksTest_static
Test: CtsNNAPITestCases
Test: ran "NeuralNetworksTest_static --gtest_filter=GeneratedTests.add",
    killed the sample-minimal driver, and confirmed (1) that the runtime
    was not blocked and (2) that the appropriate log message was recorded.
    NOTE: this was facilitated by adding a 10 second sleep in the sample
    driver for the asynchronous preparation and asynchronous execution,
    enabling the service to be manually killed via
    "adb shell kill -9 <pid>".
Test: ran "NeuralNetworksTest_static --gtest_filter=GeneratedTests.add",
    with local modifications to the sample driver to have it return an
    error message for launching an asynchronous call, but not make the
    corresponding call to callback->notify. Ensured the runtime still
    progressed and the appropriate messages were logged. Confirmed that
    without the changes in this CL, a hang occurs.
Test: ran "NeuralNetworksTest_static --gtest_filter=GeneratedTests.add",
    with local modifications to the runtime to sleep for 10 seconds before
    calling an asynchronous call. In this window, the sample-minimal
    driver was manually killed (via "adb shell kill -9 <pid>"), prompting
    a transport failure. Ensured the runtime still progressed and the
    appropriate messages were logged.
Change-Id: Ic4e8cc8399b1e30fadfaf01842ce62550ad2223f