Merge #18949: doc: Add CODEOWNERS file to automatically nominate PR reviewers

a06eb03ded1a70879db86a03c2d6831e2ed75f62 doc: Add comments and additional reviewers to CODEOWNERS file (Adam Jonas)
e02da2290619553f6fba67d8584cb1a49414bc87 doc: Add CODEOWNERS file (Wladimir J. van der Laan)

Pull request description:

  This PR brings back and builds on #17094. GitHub uses a CODEOWNERS magic file to automatically add tagged contributors to the "Reviewers" list for a PR.

  The goal of this is to make use of GitHub's suggested reviewers feature and not to confer ownership or give veto power to specific people. It would be better if this file could be named CODEREVIEWERS, but alas, that wouldn't work. The idea of a NAGFILE was proposed in [Bitcoin Core Dev meeting in 2018](https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2018-03-07-priorities/#:~:text=NAGFILE). While this GitHub implementation has some complications, it's a step towards realizing the promise of automating "reviewing begging" and (hopefully) positively impacting the review process as a whole.

  Of secondary value, this file can serve as documentation for who the maintainers are and who it might be smart to check with for certain areas of code/features (i.e., fuzzing, PSBT, and Bech32) -- this is helpful information for new contributors.

  * The first commit is taken from #17094
  * The second commit adds comments and expands the list of reviewers based on the suggestions and comments from that PR
  * ~The third WIP commit~ This commit also uses the doc dir as an example of granular assignments based on lines of codes ~contributed~ written and/or general engagement with the project. (If interested, here is a report for [most lines of code per author for each file](https://gist.github.com/adamjonas/854a46a1918224927b186865baeac411)). The pro of this level of detail is that the best reviewer is more likely to be nominated. The con is that it will create churn as files are renamed, new files are added, or reviewers want to be added or removed.

  Some open questions:
  * How often should this file be changed?
  * What level of history does one need have on the project before being added to this file? When does it make sense to remove a reviewer?
  * These review notifications can [cause a lot of noise](https://github.community/t5/How-to-use-Git-and-GitHub/Team-based-notifications-or-rework-CODEOWNERS-notification/td-p/7811) and automatically subscribes the requested reviewer to the thread. A GitHub Team based approach would allow for adding or removing reviewers without modifying this file; however, this comes along with its [own set of problems](https://bionic.fullstory.com/taming-github-codeowners-with-bots/#problems-with-github-code-owners), including granting [write access](https://github.community/t5/How-to-use-Git-and-GitHub/CODEOWNERS-works-with-users-but-not-teams/td-p/4986#U4991). Other projects [have used bots](https://bionic.fullstory.com/taming-github-codeowners-with-bots/#using-a-github-bot) to sidestep this.

Top commit has no ACKs.

Tree-SHA512: aa674ac62478b8801f48750df869c802070dc83d0fa9ff93596e9d63406129d7fd3c0daeb35d7a1a259554d045c24746a6808878a7b9867c7ed66d251f0c918f

0 files changed, 0 insertions, 0 deletions