openapi3filter: honor comma-separated and wildcard encoding.contentType

[utah-KT]

Bug

In multipart/form-data request validation, decodeBody compares a part's media type against encoding.contentType with an exact string match:

mediaType := parseMediaType(contentType)          // e.g. "image/png"
encodingContentType := getEncodingContentType(encFn) // e.g. "image/png, image/jpeg"
...
if encodingContentType != "" && mediaType != encodingContentType {
    return ... prefixNotMatchingCT ...            // "not matching content types"
}

But per the Encoding Object spec, contentType "can be a specific media type (e.g. application/json), a wildcard media type (e.g. image/*), or a comma-separated list of the two types" — and the official example uses contentType: image/png, image/jpeg.

So any part declared with a comma-separated list or a wildcard is rejected even when its Content-Type is one of the declared types. A part with Content-Type: image/png fails against image/png, image/jpeg.

Fix

• Match per the spec: split encoding.contentType on commas and accept the part if its media type matches any entry — supporting type/* and */* wildcards, comparing case-insensitively, and ignoring parameters.
• Read matched binary parts as raw bytes: a binary part (format: binary) whose matched content type has no registered decoder (e.g. image/png) is now read via FileBodyDecoder instead of failing with "unsupported content type" — the same handling binary parts already get when no encoding.contentType is set.

Compatibility

Single exact-value encodings and genuine mismatches behave exactly as before (same error and text); only previously-rejected valid cases now pass.

Tests

Added matching and binary-fallback table tests, and updated the existing multipart encoding test.