Allow multiple hardware targets in device specification

[bruno-f-cruz]

Closes #172

I will leave this PR blocked for now since we need to synchronize the release of all the json-schema spec files, and bump the respective ids

[glopesdev]

@bruno-f-cruz I was going over this old issue (#22) where we discussed whether to include patch versions or not in the device YML. Ultimately our final decision was not to do it.

I still find myself leaning to the decision we made back then, and so I want to make sure we revisit and summarise those arguments here before we decide to revert that decision:

device.yml is a specification

Specifications do not need to change with fixes to the underlying implementation, e.g. if the parsing of a string register is done incorrectly, fixing that implementation would require no change to the spec of the register itself.

Patch changes to the hardware do not need to bubble up to the specification

This is particularly relevant when thinking of the hardwareTargets part of the specification. There may be multiple hardware fixes to a device which do not bubble up to firmware or interface changes. Because each hardware target requires specific firmware builds, it would be tedious to have to explicitly declare support for every single patch in the YML, when in most cases the firmware implementation would be identical.

One might argue the patch version is relevant as experimental metadata, but this is countered by the following reasons:

• the exact information is already sent by the device R_VERSION register and logged in the initial dump
• hardwareTargets is a list of all targets and therefore, when we have multiple targets, we still wouldn't know just from the device.yml which exact one was used, and would have to look anyway into the contents of the R_VERSION register

Backwards compatibility

Previous device.yml files do not have a patch version, so keeping the spec the same would avoid having to change existing device specifications.

This would also keep the option open of reusing the same bonsai interface package to test different pre-release versions of the firmware quickly by just flashing a patch firmware, rather than forcing everyone to learn how to perform a full release cycle before deploying a hot-fix to the firmware.

Of course we can still allow synchronizing all firmware to the exact version included in the package, and this would be mandated for minor and major changes in the interface package.

I have also continued the discussion in #145 which I believe is relevant to this decision. Fundamentally we need to understand what does the firmwareVersion in the device.yml refer to, and how it relates to the unified "device version". My current understanding is that "firmware version" == "device version", but the patch version there would not have to necessarily propagate to the device.yml.