Standardise issue lifecycle

Read CONTRIBUTING.md and the linked GitHub issue-lifecycle, branch-close, and inactive-issue workflow references first. Done requires an agreed issue lifecycle, documented labels and procedures in CONTRIBUTING.md, and any selected templates or automation defined for the repository.

Current Situation

It seems like we are currently collecting old legacy issues in this repository that will be forgotten until the end of time. And since I missed the last few years of active implementation, I don't know which issues are still important and which are just outdated.

From what I understand, there are several reasons for that:

1. Auto-close: If the keywords for auto-close are missing, issues are left open and forgotten. Later, someone has to manually check which issues have already been solved. This could be a huge problem when the main SDK developers change. Examples:
   1.1 https://github.com/eclipse-basyx/basyx-python-sdk/issues/215#issuecomment-3224090385
   1.2 https://github.com/eclipse-basyx/basyx-python-sdk/issues/228#issuecomment-3224085300
2. Discussion: Sometimes, discussions are held about the IDTA specification or compatibility in general. If no updates or clear results are provided, the status of the issues stagnates. Examples:
   2.1 https://github.com/eclipse-basyx/basyx-python-sdk/issues/98
   2.2 https://github.com/eclipse-basyx/basyx-python-sdk/issues/157
3. Priority: The issues are not prioritised. Some seem less important and are therefore overlooked. After being ignored for quite some time, they may no longer be relevant. Examples:
   3.1 https://github.com/eclipse-basyx/basyx-python-sdk/issues/47
   3.2 https://github.com/eclipse-basyx/basyx-python-sdk/issues/169

Moreover, the automatic closure of issues does not really work for our workflow. When we merge an issue into the develop branch, we consider it solved. However, GitHub's auto-close feature only works when merging into the main branch, our default.

Proposed Change

Since outdated legacy issues cause major problems when devs join or especially leave the project, we should agree on a standard procedure for dealing with (open) issues. The following points could be discussed during our next dev meeting:

• Manual sorting and closing of existing issues
• Agreement on regular backlog (every 2/3/4 months?) for future issues
• Auto-close of issues merged into a non-default branch
• Auto-close of inactive issues
• Introduction of priority labels (interesting read)
• Documentation of issue labels and lifecycle in CONTRIBUTING.md
• Introduction of a template for new issues