[Task] Refactor GitHub labels

## Description
Our current [labels](https://github.com/iotaledger/identity.rs/labels) are (at least for me >.<) a bit confusing, and I sometimes have to add and remove labels to make our [label check workflow](https://github.com/iotaledger/identity.rs/blob/main/.github/workflows/enforce-pr-labels.yml) agree to the PR, which sometimes ends up in playing label battleships, or just looking into the workflow and picking the labels from that list.

## Motivation
Fully on board with enforcing the labels, but in my opinion, it might be a good idea to group our labels. Judging from the workflow, we have two groups of labels:
- affected component
- Rust
- Wasm
- Documentation
- change type
- Breaking change
- Added
- Patch
- Deprecated
- Removed
- Documentation
- No changelog

Maybe we could group them, similar to what angular does with its [labels](https://github.com/angular/angular/labels), and group the labels above into `component: *` and `change type: *` or `pr type: *`, which would make it easier to pick one of them.

Also, the issue labels are not included in the lists above, but could also be migrated into a group, e.g. `issue type: *`, if needed, which would make it easier to pick one of them when creating an issue (e.g. like this one, where I opened and closed that list multiple times already to just settle with not selecting a label).

Labels like `component: gPRC`, `component: CI`, and maybe `change type: feature set` (for long-running feature PRs with own sub PRs) might be useful.

Start with .github/workflows/enforce-pr-labels.yml and compare its enforced labels with the repository's current labels. Clarify the desired component, change-type, and issue-type groupings before changing anything; done means the label organization is agreed and the workflow consistently accepts the intended grouped labels.

Written by the indexing model from the issue text.