The dicomweb plugin incorrectly rejects requests due to bad parsing of the accept http header.

Referring to header documwentation here:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept

The value of accept can include multiple types.  Types or groups of types may be given a quality weight using the notation like this ";q=0.9".  Note the semi-colon.

Some plugin behaviour (such as making a metadata request) rejects calls when the type "*/*" is present but not present before the first semi-colon in the accept string.

So this accept string will invalidate a request:
text/html, application/xhtml+xml, application/xml;q=0.9, image/webp, */*;q=0.8

However these will both work:
image/webp, */*;q=0.8, text/html, application/xhtml+xml, application/xml;q=0.9
text/html, application/xhtml+xml, application/xml, image/webp, */*;q=0.8

A real life manifestation of this issue is that orthanc is incompatible with the dcm4che tool json2dcm.

When processing bulk data elements it makes requests using the accept value:
text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

Which is rejected even though it should be fine.

**What steps will reproduce the problem?**
Make a dicomweb request e.g. for metadata for an instance
Set the accept header such that there is a semi-colon before the "*/*" entry e.g. 
text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

**What is the expected output? What do you see instead?**
Expect the request to succeed.
The request fails.
java.io.IOException: Server returned HTTP response code: 400
Bad request: This WADO-RS plugin cannot generate the following bulk data type: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

**What version of the product are you using? On what operating system?**
1.10.0.0 Windows server 2019 datacentre

**Please provide sample, possibly anonymized, DICOM files**
Any file will work