Move CHANGES to CHANGELOG.md

[peterjunpark]

This is to align with the expectations of ROCm tool and library repos

The purpose of a changelog is to make it clear to users what has changed since the previous release. The information in the changelog should be as clear and succinct as possible, while still communicating what has changed, why it has changed, and how the changes impact the end user.

These changes must be grouped into six categories which must always appear in this order in the changelog:

Changes – Changes to existing functionality or the addition of new functionality.

Removals – Functionality or support that has been removed in this version. This information will often have been a deprecation notice in the Upcoming changes section of an earlier Release Note.

Optimizations – Component performance that has been optimized or improved.

Resolved issues – Known issues from a previous version that have been resolved. The public must already be aware of these issues. These issues have often been called out as Known Issues in earlier versions of the Release notes. They can include a link to a GitHub issue.

Known issues – A list of known issues related only to this specific component. Due to the potential ramifications of items listed in a known issues section, use judgement and discretion when adding an item to this category, and ensure that a corresponding GitHub issue exists for the item.

Upcoming changes – A list of upcoming changes, including deprecations, that we’re very confident will be introduced in an upcoming version. Do not overpromise and do not mention specific dates or versions. Items in this section should be rolled forward to subsequent release notes until the changes they describe are released.

You can omit a category if you have no changes to note under it.
The changelog file must be named CHANGELOG.md, be written in GFM (GitHub Markdown Format), and be located in the component repository's root directory. If the AMD library is a fork from another project and a changelog already exists in the project from which it was forked, name the new changelog file CHANGELOG_AMD.md.

Maintaining an (Unreleased) section at the top to track upcoming changes reduces the amount of effort needed to create a changelog file as it provides a way to track ongoing changes that can then be moved into the release section when they become available.

Changes for upcoming releases must be at the top of the changelog file, and must start with:

## (Unreleased) Omniperf 2.3.4 for ROCm 6.3.0

...

## Omniperf 2.0.1 for ROCm 6.2.0

[peterjunpark]

It should be fine to start adhering to the prescribed changelog format 2.0.1 onward

[coleramos425]

LGTM