Upgrade & Release new 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
- [ ] Create proposal as issue (you're doing this now!)
- [ ] 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

The latest version as of today is 1.4 ( released in 2015, 7 years ago ). May be its time to release and bump up the version number.

## Motivation

There's a fork of the library by Natron project ( https://github.com/NatronGitHub/openfx ) which is 1201 commits ahead of this original branch ( Not sure if those commits are specific to Natron ). Looking at the commits & discussion in the issues, there clearly is a lot of work done & going on. It would be a good idea to consolidate those changes and release a new version.

## Problem

In absence of continuous releases, the clients aren't able to make use of the hard-work added by the contributors. Also, the project appears dormant, and clients keep facing the issues with little to no help.

## Impact

Is this a new feature (no compatibility impact), a change to an existing function suite (version
the suite to avoid compatibility issues), a change to an existing property, or a documentation
change?

How will hosts and plugins negotiate use of this change? Show how it works when a host implements
it but not plugin and vice versa.

## Documentation Impact

What changes to the docs are needed for this change?

## Stakeholders

Who will benefit from this proposed change? Plug-ins, hosts, or both? Specific types of hosts?

## Discussion

No source files, tests, or entry points are named. Start by reviewing the current 1.4 release and comparing the upstream repository with the linked Natron fork, then identify the changes requiring a coordinated proposal. Done means updated headers and documentation, release notes, compatibility review, demonstrated host/plugin support, and the required stakeholder sign-offs.

Written by the indexing model from the issue text.