Add Issue templates and automation scripts

[joaopgrassi]

Fixes #773

Changes

This PR adds several automations/improvements related to issue triage/project management and a bit of dev experience for users.

The main things added are:

• Introduce concept of area - Those are the names of the yaml files inside model/registry
• Issue templates, that contain a drop-down for the area.
• Scripts and actions to automate the process of:
  • Assigning the correct area label for new issues
  • Creating new labels when new areas are merged into the registry
  • Check when new areas are introduced in PRs, so the issue templates are always up-to-date (see example here)

As a follow up, we can: (out of scope of this PR)

• Improve the CONTRIBUTING.md to add the definition of the labels and talk about the issue templates a bit
• Check if we can use the new area concept and assign those to our GitHub teams, so issues are assigned to the proper responsible party, instead of always maintainers

This work is based on what the folks over on the collector contrib repo have. (Thanks @evan-bradley!)

You can check how this looks like now in this test repository https://github.com/joaopgrassi/test-actions-otel. Feel free to create issues to test, or create PRs to verify the checks.

[pyohannes]

Given the fact that we now tag all new issues with triage:needs-triage, do you think it still makes sense to auto-assign issues to maintainers? It seems the auto-assignment to maintainers burdens them and didn't have the desired effect in the past.

For doing project management for messaging, I prefer to assign issues to folks who are actually working on it, and keep issues unassigned when nobody is working on it.

[joaopgrassi]

Given the fact that we now tag all new issues with triage:needs-triage, do you think it still makes sense to auto-assign issues to maintainers? It seems the auto-assignment to maintainers burdens them and didn't have the desired effect in the past.

@pyohannes Yes, that is true. In the linked issue I mentioned handling this as a follow up:

Follow ups after this initial work

Set up the owners/team based on area
Based on the area automatically assign the issue to the respective owner/team
More in depth definition of issue triage/from open to done, like as suggested in 

open-telemetry/opentelemetry-specification#3821

We can debate whether to leave it unassigned or assign to the proper owners/team, like they do in the collector repos.

[pyohannes]

We can debate whether to leave it unassigned or assign to the proper owners/team, like they do in the collector repos.

I'd be in favor of having it unassigned, the area:* and needs-triage labels should be enough to get the right people to look at it, but assigning it to proper owners for the given area should be fine too if that's preferred by others.