Create sigs.yml and add GC liaisons to README.md

[svrnm]

Follow up to #1955, this PR adds a GC liaison column such that one can be appointed per SIG.

@open-telemetry/governance-committee let's go through that list in sigs.yml and appoint one of us per SIG. I added a few names already, but they are in no way prescriptive, I just needed some examples for testing.

---

This PR also introduces another big change: since the SIG tables are growing quickly in the number of rows and columns (like in this PR), I propose that we extract the SIGs into a YAML file and generate the table from that. I copied the overall logic from how we generate tables in the semantic conventions.

The big advantage of this change is that it is now much easier to grow that list in both directions, the other one is that we can now apply validations, e.g. make sure that each SIG has a GC liaison, that each SIG has a slack channel.

[svrnm]

@open-telemetry/governance-committee please take a look and self-assign yourself to the different SIGs as it makes sense, based on existing relationships and other criteria where you think you are a good liaison person for an individual SIG

[trask]

I didn't list the database semconv stability SIG isn't listed on the community page since it's expected to be short-lived, but I probably should have. I can be GC liaison for it.

[svrnm]

I didn't list the database semconv stability SIG isn't listed on the community page since it's expected to be short-lived, but I probably should have. I can be GC liaison for it.

Makes it harder to track of course, but I think it can work this way as well. This here is mostly useful for long- to medium living SIGs

[jpkrohling]

I'm approving this, meaning that I'm OK in being the liaison for:

• Collector
• Go Instrumentation
• Operator
• Security