Create MAINTAINERS.md

[hendrikebbers]

As defined by LFDT every repository needs a MAINTAINERS.md file (https://lf-decentralized-trust.github.io/governance/governing-documents/repository-structure.html). A template provided by LFDT can be found at https://github.com/LF-Decentralized-Trust/governance/blob/main/tac/governing-documents/SAMPLE-MAINTAINERS.md

This PR creates the first MAINTAINERS.md file for a Hiero repo. The file contains a lot of definitions and rules. Therefore it must be reviewed by the TSC before we move forward and create new repositories.

Based on the guideline of LFDT for the MAINTAINERS.md file (see https://lf-decentralized-trust.github.io/governance/governing-documents/MAINTAINERS-file.html), at least one contact method needs to be provided for each maintainer. Currently the table has not filled any contact method. I suggest to use email by default but want to discuss that before publishing mails in the file.

[popowycz]

• There is nothing here that speaks to timeliness. Is there any expectation by contributors regarding the timeliness in acting on contributions by maintainers?
• Compliance with the organization's policies - I would recommend that we include that maintainers are the primary overseers ensuring that activities in their repos are compliant with the policies of Hiero and LF-DT. Example being complying with the LF-DT security vulnerability disclosure policy.
• I would also recommend that we highlight the maintainers responsibility in fostering an environment as outlined in the Code of Conduct.
  
• Regarding the test and release pipeline and the publication of artifacts, from a good practices perspective, I would recommend we have a document/procedure which outlines what the expecations are (e.g. artifacts should include all variable test parameters/inputs).
• Regarding becoming a maintainer - is there a definition of what a "significant" PR is?

[rbair23]

It would be nice to get this lined up (also it looks like there may be tabs in here)

[rbair23]

I think for us, we distinguish between committers and maintainers, whereas LFDT may not in general. I think the bar to becoming a maintainer is far higher than 5 significant merged pull requests, although for a committer this may be about right. I think we need to revisit this language. Maintainers have voting rights, and that should come with a long history of active participation.

[rbair23]

Just a formatting comment -- some lines are short, some lines are really long. I think we should reformat so we have as a rule 120 chars per line, like we do source files.

[rbair23]

There is no mention of maintainer votes of NO. So suppose less than a majority agree with the PR, so they don't approve the PR. But then after two weeks only 3 maintainer PR approvals were needed to merge the PR. I also assume a single NO by a maintainer is not sufficient, otherwise two bad maintainers colluding together could avoid ever being removed. instead, there has to be some voting process, and I am skeptical that the PR approval process is the best way to do it (since tallying up the results is difficult).