feat: add ability to abort running OTA

[Nerivec]

On paper (i.e. spec), this should allow to abort an in-progress OTA.
Though, since vastly untested, and with the many stacks out there, it needs testing with various devices to ensure no undesired behavior can result of this.
The device has to properly process the response, and abort the OTA process on its side. While it should be fairly simple, the lack of handling could send the device into a permanently unanswered repeat of last block request (until it eventually times out on its end, if). I guess worse case scenario, albeit unlikely, would be bricking the device if for some reason the abort isn't properly handled (could try to flash with a partial image, keep a partial image in slot that could mess with device state detection...).

@andrei-lazarov @burmistrzak if you have some time to test this with actual devices.

[burmistrzak]

Question is, what do we do when a devices replies with Malformed Command and requests another block afterwards to continue OTAU?
IIRC, that's especially an issue with Hue accessories Koenkk/zigbee2mqtt#31590 (comment)

[Nerivec]

@burmistrzak this should already be fixed in #1758. We can just ignore the malformed since the device is expected to continue requesting blocks at the proper offset. The ignore was missing, which caused the undesired state after the recent PR that added default response matching.

[burmistrzak]

@Nerivec That's good to know! I've got a bunch of outdated Hue remotes still around. So I should be able to verify the fix. 🤞🤞🤞