CMSIS-DAP v2.1 initial support

[flit]

This change set updates DAPLink to use CMSIS-DAP v2.1. The new DAP_Info values are fully supported and can be customised per board and target. Integration of the UART over DAP feature with DAPLink's existing virtual serial interface is not included in this PR and will be added later.

These DAP_Info values are modified:

• Product Name (0x02): Set to "DAPLink". (The Vendor Name field is left empty.)
• Target Device Vendor (0x05): Returns the new target_cfg_t::target_vendor field.
• Target Device Name (0x06): Returns the new target_cfg_t::target_part_number field.
• Target Board Vendor (0x07): Returns the new board_info_t::board_vendor field.
• Target Board Name (0x08): Returns the new board_info_t::board_name field.
• Product Firmware Version (0x09): Set to the DAPLink version, e.g. "0256".

Board names have been set for the micro:bit v1 and v2 boards, and target names have been set for all nRF5x targets. These can be used as references

A new documentation file, string_customization.md, is added to fully document the above as well as how to configure other user-visible strings.

Note that this change corrects the kTargetConfigVersion constant that was recently added to be 1, synchronised with kBoardInfoVersion. Incrementing the struct versions was considered, but given that there are no known existing uses of board and target data being added post-build, we decided to start the version at 1 for the upcoming 0256 release.

An additional change that should follow this at some point is to report the values of the target and board names in the details.txt file.

[mbrossard]

There was a compilation issue that I fixed in [cc36a68]. I also started to add some target information, but as you can imagine it is a very slow process, and this PR should go in as soon as possible.

[mbrossard]

Because g_board_info is const, you cannot set the board name and vendor at runtime. Maybe we should (add an option to) change DAP_GetTargetBoardVendorString() and DAP_GetTargetBoardNameString() to be __WEAK instead of __STATIC_INLINE.

[flit]

Oops, sorry about the build error. I did a full build, but apparently before I removed the version increments. *sigh*

If we make the string functions weak, they'll need to be moved to a .c file. I'll look at it.

[flit]

If we make the string functions weak, let's do it in another PR.

[tom-van]

I have a question about DAP_PACKET_SIZE definitions which appeared first in this commit.
DAP_PACKET_SIZE is defined conditionally for some hic_hal targets supporting USB FS only, e.g. freescale/kl26z, kl27z, stm32/stm32f103xb and possibly others:
eebc1b1#diff-49941c311a09961f84f88382c18e3742cc63134e9bd6cb868e254836a6a2c844R87-R88

Is it just a copy & paste error, in fact not intended for USB FS devices?
Or do you really want to use CMSIS-DAP packets longer than the longest possible USB bulk packet in case of USB bulk only configuration? In theory it could work if both the probe and the debugger handles bulk ZLP correctly, but seems me contrary to CMSIS-DAP specification.