Etag extraction from header incomplete?

**Describe the bug**

The method `ControllerUtils::getEtagFromHeader` is supposed to extract the Etag, but it only checks the `If-Match`
header, which makes it interesting for updating resources only.

https://github.com/kit-data-manager/service-base/blob/6f56555ce5443f09256c09015a75be9305e56750/src/main/java/edu/kit/datamanager/util/ControllerUtils.java#L145

According to [this article](https://www.baeldung.com/etags-for-rest-with-spring), another header may be relevant in other cases, although spring usually handles this for us.

> Using an If-* header turns a standard GET request into a conditional GET. The two If-* headers that are using with ETags are “[If-None-Match](https://datatracker.ietf.org/doc/html/rfc2616#section-14.26)” and “[If-Match](https://datatracker.ietf.org/doc/html/rfc2616#section-14.24)” – each with its own semantics as discussed later in this article.

The linked RFC in the article is an outdated draft, [the current version is here](https://datatracker.ietf.org/doc/html/rfc9110#section-13.1). Both mention the "*" wildcard, and supporting a list of etags. Not sure but I think we do not support this (in this manual check, at least. Spring probably does.)

**To Reproduce**

Nothing to reproduce. I found it while checking available utilities.

**Expected behavior**

- The documentation should make clear that this function is only appropriate for update cases / the if-match header.
- There could be a function handling multiple values and wildcard ("*"). This function may be used for different check functions, like the ones already provided.

**Screenshots**

None. Check out the links to the source code and the article above.

**Desktop (please complete the following information):**

Independent. Just talking about the source code here.

**Additional context**

none

Start in src/main/java/edu/kit/datamanager/util/ControllerUtils.java at getEtagFromHeader and read the issue’s RFC 9110 reference for If-Match, If-None-Match, lists, and the wildcard. Clarify whether the intended result is documentation of the current update-only behavior or a generalized helper, then define completion around that agreed behavior.

Written by the indexing model from the issue text.