Add patch component to HarpVersion

[glopesdev]

A new optional PatchVersion property is added to the HarpVersion class for compliance with the new R_VERSION register. ToString and Parse are adapted for backwards compatibility, and allow omitting the floating patch version.

The FirmwareMetadata class is also refactored to allow for optional patch versions on all version strings. The CoreVersion property is renamed ProtocolVersion for compliance.

[glopesdev]

@bruno-f-cruz @filcarv This is a first pass at upgrading HarpVersion to allow representing the new spec for R_VERSION.

I briefly wondered whether we could also extend FirmwareMetadata to represent the entire R_VERSION register, but there are a few kinks which would have to be ironed out:

• AssemblyVersion is not part of the R_VERSION register. I believe this entire version number has now been deprecated from the spec, so perhaps we could just make this property obsolete?
• PrereleaseVersion is not part of the R_VERSION register. One option might be to represent it in the filename string, but not in the firmware R_VERSION register, so that FirmwareMetadata objects constructed from the device over serial would always have an empty PrereleaseVersion.
• DeviceName is not part of the R_VERSION register. For operators constructed from auto-generated interface packages, this issue could be resolved by pulling the correct name from the device.yml resource embedded in the assembly.
• Both SdkId and InterfaceHash are part of R_VERSION but are missing as properties in FirmwareMetadata. This is not necessarily a problem, since we could simply add these new properties. For consistency we would need to allow including them in the ToString format so it could be parsed back from the metadata string name. This might not necessarily be a bad thing as it would make filenames more informative, albeit more verbose, e.g.:

Behavior-fw3.3-harp1.15-hw2.0-ATX-aeb6f8b8c166487417f9.hex

We can discuss this option at SRM soon. Otherwise I can always just create a VersionPayload class.

[glopesdev]

Feedback from SRM:

• PrereleaseVersion could be filled in from the auto-generated interface (need to investigate).
• We should add ATX and RPI as constants to the JSON schema
• Probably worth trying to stretch FirmwareMetadata if we can make it backwards compatible