Add CLI Burn Bootloader Command

[davidcooper1]

Description

This PR integrates the burn-bootloader command into this extension when using arduino-cli. Functionality needs to be added to the Arduino IDE command line before full support for both can be integrated. An issue has been raised upstream to request this feature be added to the Arduino IDE (arduino/Arduino#11765).

To Test

1. Get an ISP whether using another Arduino as ISP or using another ISP supported by arduino-cli.
2. Select board to burn bootloader to.
3. Select programmer to use as ISP.
4. Run the Arduino CLI: Burn Bootloader command.

Expected Result

Bootloader has been burned to the selected board successfully.

Additional Notes

• Command errors out when not using arduino-cli since this feature is not yet supported using the IDE command line.
• arduino-cli v0.12+ is required to run this command.
• Please reach out with any suggestions/errors! This is my first PR in this repo to integrate additional functionality as opposed to bug fixes.

Partially Fixes #967

[gcampbell-msft]

If I'm understanding this right, this forces someone to select the port, and then have to restart the burn bootloader process. Is this what you were going after?

[davidcooper1]

Yes, I was using the same flow found in _build() for this just to be safe. I do like the idea of allowing burn bootloader or build operations continuing if a serial is selected though. It may be worth bringing this up in a separate issue.

[gcampbell-msft]

This is located in a try catch, but the _burnBootloader method seems to primarly use the boolean return value to signal success or failure.

[davidcooper1]

Here I mostly followed a similar flow to build() which handles potentially unhandled exceptions.
Originally the code was like the following:

return await thenable.then((ret) => {
    // setState
    return ret;
).catch((reason) => {
    // setState
    // logReason
    return false;
});

I figured that a try catch finally approach would do the same task and appear more readable and reduce the repeated lines that set the state. The only difference being that the state is set after the operation returns.

try {
    return await thenable;
} catch (reason) {
    // logReason
    return false;
} finally {
    // setState
}

I'm open to suggestions though!

[gcampbell-msft]

/azp run