Flashing target hex file in MAINTENANCE mode soft-bricks micro:bit since bootloader 0241

**Description:**
We often get user reports of micro:bits "stuck" in MAINTENANCE mode, that can only be returned to MICROBIT mode after they flash a DAPLink interface hex.

We believe the cause is due to the relative simplicity of entering MAINTENANCE mode by accident, eg. by pressing reset when inserting the USB cable, and then flashing a target micro:bit hex in this mode. When this happens, it is not obvious to users why the micro:bit is not flashing their programs anymore, or how they can fix it

**Steps to reproduce the behaviour:**
Using an out-of-the-box micro:bit 1.5 with bootloader 0243 (the default for the 1.5 revision)

1. Put the device into MAINTENANCE mode
2. Flash hex from [microbit-heart.hex.zip](https://github.com/ARMmbed/DAPLink/files/4751157/microbit-heart.hex.zip)to device
4. Device restarts in MAINTENANCE mode
5. Unplug and replug USB. The device still starts in MAINTENANCE mode

**Expected behaviour**:
Flashing a target hex whilst in MAINTENANCE mode should generate a FAIL.TXT saying "The hex file you dropped isn't compatible with this mode or device. Are you in MAINTENANCE mode? See HELP FAQ.HTM"

This was the behaviour as designed with the BBC and released in DAPLink Bootloader 0234 for all the original micro:bits.

**Additional information**:
It looks like this behaviour is by design and was introduced at 0240 in https://github.com/ARMmbed/DAPLink/commit/c130e3af71df11322565edcba246596538c1960b as a means to allow 3rd party images to be flashed in bootloader mode.

We have tested this up to version 0254 as well and the issue is still present.

To resolve this, could DAPLink re-enable interface image validation and if so can it be bypassed via automation? So that, for example, if J-link wants to make their software available to the micro:bit firmware chip, they could either add the same validation or instruct the users to copy the hex file into the MAINTENANCE drive while the reset button is pressed.

If making this change would affect other DAPLink boards, could this validation mode be enabled on a per-board basis, or via some type of configuration?

Review commit c130e3af71df11322565edcba246596538c1960b and reproduce the MAINTENANCE-mode flashing sequence described in the issue. Trace where interface image validation and FAIL.TXT handling are configured, then verify that incompatible target hex files produce the stated failure message without preventing supported automation paths.

Written by the indexing model from the issue text.