Release v2.0.0 Beta - Issue#10476

[syskovprdap]

ofiwg/libfabric#10476
Update this procedure with any new providers. Copy/paste markdown as new issue for each new release, and update as necessary.

1. 1. Make a perfect tarball

• For libfabric:
• [x] For new minor releases (v1.Y.0), make stable v1.Y.x branch
• [x] Cherry-pick relevant commits from main
• [x] Update the libfabric version number in `configure.ac` to the final release version
• [x] Update the version number in include/windows/config.h
• Update the version numbers in `include/rdma/fabric.h`
• [x] FI_VERSION_MAJOR should match first number in configure.ac
• [x] FI_VERSION_MINOR should match second number in configure.ac
• [x] FI_REVISION_VERSION should match the revision value (x in v1.Y.x)
• [x] Update providers to support the version in fabric.h
• This should update automatically with above changes.
• [x] Update the shared library version number(s) in `Makefile.am` [per the GNU Libtool shared library version number rules](https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html)
• General rule, bug fix release: c:r+1:a
• General rule, minor release: c+1:0:a+1
• Always check the libtool rules, but as general rules: Stable releases (v1.x.y - where y is updated) should never see API changes; stable release c:r:a versions should normally be updated to c:r+1:a. Minor releases (v1.x.0 - where x is updated) may see API additions or backwards compatible API changes. If there are no API changes, minor release c:r:a versions should be updated to c:r+10:a relative to the highest numbered stable release. The r+10 allows for up to 9 additional stable releases without resulting in a collision in the release numbers. If there are new APIs or backwards compatible changes, update c:r:a to c+1:0:a+1. Just say no to all non-compatible API changes. Note: given version c:r:a, the installed library will be named as libfabric.so.v.a.r, where v = c-a.
• Pro tip: run `git log --stat --no-merges > log.txt` as the head of the master
• Examine this file all the way back to the Git tag for the previous release; look for changes to files in `src/`, `include/`, and `include/rdma` to help determine if the `c:r:a` version values need to change
• Pro tip: run `git log ..HEAD – include/rdma`
• Will show all changes to the external header files since the last release. The last_version_tag should be similar to `v1.3.0`
• Update all documentation files (especially including dates and version numbers), including:
• [x] `README.md`
• [x] `AUTHORS` (via `git log --pretty=format:'%aN