Automatic flashing capabilities

[rneacy]

This PR allows for the automatic flashing of the micro:bit through the use of a new flash.py script stored in utils/python.

It provides both compatibility with build.py and VS Code.

The changes summarised:

• Adds a -f (flash) flag to build.py which will attempt to automatically find and then flash a connected micro:bit.
• Added a VS Code task that allows people to flash without leaving VS Code.
• Modify README.md to demonstrate the new flashing capability.

[JohnVidler]

While I like the idea of including this in build.py, I think it needs a little further refinement before we include it.

Specifically, there doesn't seem to be a way to handle the edge case where multiple micro:bits are connected at once; you'll just get the first one in the volume list. I would personally prefer this to grab all connected micro:bit boards (or others, which include a DETAILS.TXT file) and list them as we see for such tools as adb for Android, whereby the user can either specify a device ID, or an index in the connected devices list to select the device.

Something along the lines of the following fake terminal chat might be good:

$> ./build.py -f ↵

There are multiple devices connected:
    1. micro:bit - 9900000048154e45001560140000005d0000000097969901
    2. micro:bit - 9900000048154e450044600e000000610000000097969901

Please select which device to flash with either an ID or an index; eg. build.py -f 2

$> ./build.py -f 9900000048154e45001560140000005d0000000097969901 ↵
micro:bit path: /mnt/ ...

(Note: it's a bit of a shame that we don't have a shorter ID to hand - perhaps something to have configurable in the future? Device friendly name in the DETAILS.TXT to use as an alternative to IDs or offsets here?)

It might even be useful to have a seperate --devices option, perhaps even with a --format=json optional flag to get the connected devices list for external tooling.

I welcome discussion on this, maybe @microbit-carlos and/or @finneyj wish to comment?

In the mean time, I've resolved the conflict with the updated README in master, and I'll push that merge here so we can work from a more current base.

[JohnVidler]

Having thought more about this and spoken to @finneyj , I think its probably better to make this a seperate tool (I suggest we work towards a flash.py) which uses the target module to determine how to flash each device, that way each board maker can customise the steps without them merging into one giant tool.

I'll be working on this in the coming days, and will leave this PR open for now to report on it, but its unlikely that this will be merged in if we go down this route.

[finneyj]

Thanks @JohnVidler. Yes, I think refactoring this core of this PR into a separate tool makes a lot of sense... so your work will live on @rneacy!

[JohnVidler]

Close for now, as this functionality should be presented as part of codal-bootstrap, and the new library-based tooling