feat(http/unstable): implement RFC 9651 Structured Field Values

[tomas-zijdemans]

Implements RFC-9651 parsing and serialization. RFC 9651 obsoletes RFC 8941 and is fully backwards compatible, adding support for Date and Display String types.

• Single file implementation (like http/user_agent.ts)
• Browser compatible
• Matching RFC 9651 terminology as much as possible
• Has all RFC 9651 types, including dates and display strings that extends RFC 8941
• Official HTTPWG conformance test suite included in testdata/structured_fields/ (JSON files from https://github.com/httpwg/structured-field-tests)

[codecov]

Codecov Report

❌ Patch coverage is 94.53015% with 39 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.22%. Comparing base (823ee48) to head (b4acd4c).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
http/unstable_structured_fields.ts	94.53%	38 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##             main    #6963    +/-   ##
========================================
  Coverage   94.21%   94.22%            
========================================
  Files         615      616     +1     
  Lines       47840    48553   +713     
  Branches     8320     8527   +207     
========================================
+ Hits        45074    45749   +675     
- Misses       2699     2736    +37     
- Partials       67       68     +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[tomas-zijdemans]

Test coverage is not 100%, this is due to defensive programming. In practise I would argue it's 100%.

Please advise if I need to address the patch test coverage.

[kt3k]

We tend to avoid these type of prefixed names like SfItem, SfDate, etc (especially in public API names). How about removing these prefixes? (I personally think it's fine to make some conflicts with builtins such as String, Date)

[tomas-zijdemans]

We tend to avoid these type of prefixed names like SfItem, SfDate, etc (especially in public API names). How about removing these prefixes? (I personally think it's fine to make some conflicts with builtins such as String, Date)

Thanks for the guidance, I was back and forth on this.

[tomas-zijdemans]

Ready for re-review

[kt3k]

LGTM. Thank you!