[Bootloader] Return an error if busy or in an unavailable state

[isaacvr]

Feature description
When sending a request to the bootloader while it is busy or in an unavailable state, it responds nothing. It should return an error indicating in some way that is it not possible to do what was requested.

Is your feature request related to a problem? Please describe.
I did the following using the js library:

1. I used the devUpdateFirmware function for updating the device and obtained this output:
   
   Also, the device showed this:
   

2. While having the console in focus, I pressed ctrl+c. That canceled the operation in the pc, but the hardware wallet was still waiting for user input. In this state, I called devUpdateFirmware again a got this output:
   
   It is important to note that the error message did not appear quickly, but after some time. This appear to indicate that the error message appeared because of a timeout and not because the device responded something in particular. Also, it was interesting that while the device was waiting for user input, the calls to the getDevice function also failed after some time, so the bootloader is not responding to them while waiting for input.

3. I cancelled the operation in the device, so the screen ended in this state:
   
   After that, I called devUpdateFirmware again a got this output:
   
   After the last line nothing else happened, neither on the device nor on the console, so the operation was stuck.

Testing in the console, this could appears like normal behavior, but carries some complications for the integration with a GUI. this is an example (this happened while creating the updater in the desktop wallet, using the daemon):

If the user tries to update the firmware and by accident cancels the operation, the device screen will ask the user to reconnect the hw wallet, but the user could simply retry using the desktop wallet. In that case, the hardware wallet will do nothing but the desktop wallet will ask the user to confirm the operation in the hardware wallet. It will stay like that for 50 secons until the http connection times out.

Describe the solution you'd like
In the previous examples, instead of not receiving a response, an error should have been received. An example is that if I use the devWipeDevice function while the device is in firmware mode and call devWipeDevice again while de device is still waiting for user input, this is the console output:

Describe alternatives you've considered
The previous example about how the firmware reacts shows a possible solution, but in fact the implementation does not need to be the same. What is important is to have any kind of error, so the GUI can know that something went wrong with the operation and tell the user that the procedure was cancelled.

Additional context

Possible implementation