[DOC] Add Errata documentation

[clayton8]

No description provided.

[calebofearth]

We could take a few different approaches to maintaining the Errata file. We should document which one it is.

Candidate Processes

Process A

• After cutting a release, any known issues are documented in Errata.md and pushed to all applicable release branches as a doc-only update
• Those issues should be resolved in either a future patch or future minor version, at which time Errata.md is updated, only for the branches where the fix is applied.
• Each minor release is considered to start from a blank slate in terms of Errata, meaning all prior Errata should be resolved before that release can be made, so this file is refreshed with only new/outstanding Errata at the time of the release, then updated later.

Process B

• Whenever any Errata is discovered, it is added to the md file in main, then cherry-picked to the applicable release branch errata file(s).
• Each patch branch maintains a comprehensive list of all errata discovered prior to that release being cut, plus any new errata that are documented for that specific patch branch after-the-fact.
• main branch contains a comprehensive list of all known errata in all releases, and Errata entries are never deleted from the file (for traceability).

Suggestions:

1. Add Errata updates as a checklist item in the release process doc. We need some verbiage to define exactly how the Errata file is maintained.
2. We might consider naming the Errata something like ERRATA-v<MAJOR>.<MINOR>.<PATCH>-###, to make it perfectly clear how Errata can be differentiated. We wouldn't want to define ERRATA-000 for v2.1.1, then fix it in v2.2, then cut v2.2, then realize we need to document a new issue and also wind up calling it ERRATA-000. This is heavily dependent on the process we follow for this file.
3. Each Errata should have a section that defines the earliest version to which it applies. Since we're only applying doc updates to the tip of the patch branches, it's important to know which versions the errata applies to. We might also have a section that lists which version the Errata was resolved in.
4. It should be mandatory to tie the Errata to some GitHub issue that is filed.

[calebofearth]

Embedding Errata in the integration spec might become a bit onerous over time. I would think the presence of an Errata file is sufficient.