API version

# Open Effects Proposal for Standard Change

Please read the contribution [guidelines](https://github.com/ofxa/openfx/wiki/Extending-OpenFX-Guidelines#submit-a-proposal-or-bug-report-to-review) first.

## Standard Change Workflow
- [X ] Create proposal as issue (you're doing this now!)
- [ X] Tag this issue with `standard change` tag
- [ ] Identify subcommittee: at least one plug-in vendor, and at least one host
- [ ] Discuss the idea in this issue
- [ ] Write new or updated code and doc
- [ ] Publish updates as a pull request (ideally on a `feature/PROPOSAL-NAME` branch)
- [ ] Make sure that PR references this issue number to keep them in sync
- [ ] Discuss and review code in the PR
- [ ] Meet all requirements below for accepting PR
- [ ] When subcommittee signs off and other members don't have any further review comments,
maintainer merges PR to master which closes PR and issue

## Requirements for accepting a standard change:
- [ ] Header files updated
- [ ] Documentation updated
- [ ] Release notes added
- [ ] Compatibility review completed
- [ ] Working code demonstrated with at least one host and one plugin
- [ ] At least two members sign off
- [ ] No further changes requested from membership

## Summary

We don't define explicitely the API version as a string at least anywhere. We do have GetAPIVersion but it's not clear it's being properly updated/referred to.

## Motivation

Although API version should not be a conditional for compliance, it's a good practice when adding features in API to mark the version this was added with context.

## Problem

Adds an explicit version string. Suggestion is to add "1.5" in ofxCore and a top level text file with sub-version, e.g. 1.5.5, for each API update. The sub-version would be used to in parallel update the wiki entry with Issue/PR number. This way a developer can see what was added since they last downloaded master and at a glance understand what matters to them.

## Impact

Provides a way to source API version in non-ambiguous manner.

## Documentation Impact

When you google the version displayed would be auto-accurate.

## Stakeholders

All

## Discussion

Start by reading the existing GetAPIVersion implementation and the ofxCore headers to see how the current API version is exposed. Review the proposal's suggested top-level version file, then map the required header, documentation, release-note, compatibility, host, and plug-in updates. Done requires agreement from the identified subcommittee and signed-off code and documentation in a pull request.

Written by the indexing model from the issue text.