Add a sssom_version slot

[gouttegd]

Resolves [#439]

• docs/ have been added/updated if necessary
• make test has been run locally
• [ ] tests have been added/updated (if applicable)
• CHANGELOG.md has been updated.

If you are proposing a change to the SSSOM metadata model, you must

• provide a full, working and valid example in examples/
• provide a link to the related GitHub issue in the see_also field of the linkml model
• provide a link to a valid example in the see_also field of the linkml model
• run SSSOM-Py test suite against the updated model

This PR adds the new sssom_version set-level slot suggested in #439.

Contrary to the original suggestion of using a xsd:string-typed slot, it uses a enum-typed slot, with a new sssom_version_enum slot whose values represent the different versions of the specification (for now, the current 1.0 version and the upcoming 1.1). This should allow implementations to very easily check whether the version found in a set is one they support or not: if the value is not one of the “permissible values”, then either it’s a completely bogus value, or it’s one from a more recent version of the model than the one supported by the implementation.

It also add a new section in the documentation of the model, to explain how to deal with that sssom_version slot and, perhaps more importantly, to explain what are our promises regarding the evolution of the specification and backwards compatibility. That part may require further discussion before it is accepted, but it mostly follows the discussion that happened in #325. Basically, we promise never to break backwards compatibility across minor versions, which notably means that:

• a new minor version may only add new slots or enum values, but never remove a slot or an enum value;
• when adding a new slot in a minor version, that slot must be optional (possibly recommended, but never mandatory);
• a new minor version cannot make mandatory a slot that was previously optional.

Any change to the spec that would make invalid a set that was previously valid, MUST happen in a new major version, for which we do not make any blanket promise of backwards compatibility.

Lastly, it adds a new meta model extension, Versionable, that can (and should) be used to mark any slot that has been added post-1.0.