Add patch version to SDFormat spec to account for elements added between minor versions

[scpeters]

Desired behavior

We currently define the specification version in an SDFormat file with a MAJOR.MINOR version. The minor version can be updated with new major versions of libsdformat, but we periodically add new features to a released version of the specification without increasing the version number. It would be nice to increment the patch version of the specification when new features are added. Then if a file wants to use a feature that is not available in all version of X.Y, it can specify X.Y.Z. The parser can give a warning or fail if it is passed a file that with an unsupported patch release version.

Alternatives considered

Implementation suggestion

Additional context

[scpeters]

I've been thinking about how to describe the user stories for this feature, and I've identified the following users with brief stories:

• SDFormat specification contributors (specifically the contents of the sdf/ folder in this repository):
  • It is desirable to be able to add non-breaking features to the specification (it is already a quite common practice)
• libsdformat parser developers:
  • There is significant overlap between this group and the SDFormat specification contributors. The parser should be able to provide feedback if a file being parsed contains unrecognized features. As of bitbucket PR 449, unrecognized elements are copied along with only a message logged to the ~/.sdformat/sdformat.log file, which is not commonly checked.
• Developers of other SDFormat parsers (such as gzsdfparser.js in gzweb, which currently only supports up to 1.6)
  • Each change to the specification introduces additional work to 3rd-party parser developers in order to support the latest changes.
• Package managers that host libsdformat (Debian, Ubuntu, Conda, etc):
  • Some of these package managers will not accept new package versions with feature updates to a released distribution and will only accept critical security updates
• SDFormat file authors
  • They want their models to be usable by a community of users. They may choose to target an older version of the specification to maximize support for different software versions (ie 1.6 to support gazebo9, gazebo11 and Citadel+) or they may target a newer version of the specification in order to use more recent features. In general, these authors are less familiar with the differences between versions of the specification than contributors to the spec.
• Users who load SDFormat files (such as users of gz-sim)
  • I think they don't really care what version they are using, but they will appreciate clear feedback if they attempt to load a model with unsupported features. They may decide to try using the model anyway or to upgrade to a more recent version if it is clear how to do so.

[scpeters]

we should document this issue about different versions of a parser being unable to recognize elements added to the spec after its initial release

[scpeters]

we could consider declaring the version each element was added in the spec, and inheriting the values so they don't need to be explicitly encoded everywhere in the spec