Consider relaxing wildcard validation strictness in WildcardListHeader for parsing

[coderabbitai]

Problem

The current WildcardListHeader<T> implementation strictly rejects mixing * with other values during both parsing and generation:

if (splitValues.length > 1 && splitValues.contains('*')) {
  throw const FormatException('Wildcard (*) cannot be used with other values');
}

While this prevents semantically meaningless combinations (e.g., Access-Control-Allow-Headers: *, Content-Type), it may be too strict for parsing headers from external sources.

Design Tension

Generation: We want to prevent creating semantically contradictory headers
Parsing: We want to handle syntactically valid but semantically questionable input gracefully

This follows the "be liberal in what you accept, conservative in what you send" principle.

Potential Solutions

1. Separate validation paths: Allow mixed wildcards during parsing but prevent them during construction
2. Parse permissively, expose conservatively: Parse everything but provide methods to detect/handle semantic issues
3. Configuration-based: Make wildcard strictness configurable per header type
4. Current approach: Stay strict on both sides (status quo)

Context

Discussion originated in PR #159 regarding the base class design for wildcard-enabled headers.

Backlinks:

• PR: refactor: Introduce WildcardListHeader<T> base-class #159
• Comment: refactor: Introduce WildcardListHeader<T> base-class #159 (comment)