Add versions of the consent forms and other docs

regardless or in addition to proper i18n support (now we have [i18n teams](https://github.com/orgs/con/teams/i18n/teams) btw) we need to start versioning the form(s) which would help to also track which translation needs additional changes from previous one.

Two major choices:
### use this repo version as a base

`.[ult|gdpr|dpi|dua][.][.language[.LANGUAGEPATCH]]`

#### pros

- simple to "implement"
- aligned with the releases of this repo so it would be easy to see differences between two specific versions .

#### cons

- jump in big progressions whenever even trivial changes introduced

### use separate versions per each document

Use https://semver.org/ at large in a form `MAJOR.MINOR[.language[.LANGUAGEPATCH]]`, with simple logic of
- `MINOR` goes up upon trivial changes -- typo fixes, reformatting etc.
- `MAJOR` going up whenever anything added to removed.
- `.language` is an abbreviation based on https://www.w3schools.com/tags/ref_language_codes.asp
- `.LANGUAGEPATCH` - any changes accumulating on top of `MAJOR.MINOR` for that language. No `.language` for english version as the source of all translations. So versions could be `1.0` `1.0.es.2` . And then when we see main version `1.2` but translation still `1.0.es.2` we would know that we should update to the changes in that translation between versions 1.0 and 1.2 of the base version.

Start by reviewing the two versioning approaches in the issue, along with the linked semver and language-code references. No files, tests, or entry points are named, so first identify where the consent forms and related documents live. Done means an agreed versioning scheme is documented and its required implementation scope is clear.

Written by the indexing model from the issue text.