Add core register schema with protocol version

[glopesdev]

Following discussions in #22, this PR introduces a core register schema with a protocolVersion field specifying the minimum semantic version mandating a given set of common registers.

The new JSON schema is named core.json and is to be used by both the common register metadata file and each of the device.yml files.

The common register metadata file is also renamed to core.yml to avoid the unusual terminology of "common". In Harp parlance, the "core" is always what we talk about when discussing requirements for hardware devices. There is no direct reference to this metadata file other than from the generator and analysis packages, which will be themselves updated in the near future to embed the new core.yml. Since these packages distribute their own snapshots, changing and renaming this file is not expected to be breaking.

Also added regex validation patterns for all version strings, adapted from semantic versioning with only a major and minor version component: ^(0|[1-9]\\d*)\.(0|[1-9]\d*)$

Fixes #22
Fixes #65

[bruno-f-cruz]

Discussions during SRM:

Consider device.yml as an interface specification with that in mind all fields should be tracked of as Major.Minor.
Instead of keeping track of the architecture, use the hardware targets (e.g. hw_target {hw_version, architecture_enum, archicture}. Where architecture_enum comes from #44 (comment).

What to do with the version of the protocol implementation version?
@glopesdev argues that, until we decide what we really want people to use the device.yml for (e.g. interface definition vs manifest file for the whole device) this version should not be tracked for now at the level of the device.yml. It should be noted that this does not kill the affordances already provided by reading the version register directly as of (#44).