Remove SuperHeaders class, add new from header methods

[markdalgleish]

This PR removes the SuperHeaders class from @remix-run/headers in favour of individual header parsing functions and updates all consumers to use the new utils.

• @remix-run/headers no longer exports SuperHeaders/Headers class. Instead, it now exports individual .parse() methods for each header class (e.g. ContentType.parse(), Accept.parse(), etc.) along with parseRawHeaders() and stringifyRawHeaders() utilities.
• @remix-run/fetch-router now returns a plain Headers instance from RequestContext.headers instead of SuperHeaders, and has dropped the @remix-run/headers peer dependency.
• @remix-run/multipart-parser has been updated to use the new header parsing functions.
• @remix-run/response has been updated to use the new header parsing functions.

[MichaelDeBoey]

@markdalgleish If this PR is created to fix #10872, an alternative could be to go with @alexandredev3's solution from #10889

[markdalgleish]

@MichaelDeBoey Just repeating my comment here from #10913 for anyone who missed it.

We were aware of this and explored what a complete solution would look like here: #10904. We've opted instead to simplify the model and avoid this category of issue entirely.

[mjackson]

Thanks for putting together this PR, @markdalgleish. I was thinking about this PR over the break, and it occurred to me that we could use from methods to possibly clean up the API a bit.

Instead of exporting both the header class and a parse method (e.g. AcceptEncoding and parseAcceptEncoding) we could just add a static AcceptEncoding.from(init: AcceptEncodingInit) method that would do the work the constructor is currently doing. I like this for a few reasons:

• We don't have a bunch of parse methods, instead we just export a single class for each header (and an init type)
• The parse method was always returning an instanceof its associated class, which is what from is traditionally used for in JS array methods (e.g. Array.from(), Uint8Array.from(), etc.), so this feels a little more "native"

We can also preserve the ability to pass an optional init value to the constructor by using the from() method internally if it's present.

class AcceptEncoding {
  static from(init: AcceptEncodingInit) {
    let header = new AcceptEncoding()
    // iterate over the init object and use set()/append() methods to add values...
    return header
  }

  constructor(init?: AcceptEncodingInit) {
    if (init) return AcceptEncoding.from(init)
    this.#map = new Map()
  }
}

What do you think?

[markdalgleish]

@mjackson Yeah, that feels cleaner. I've pushed an update moving to this pattern.

[mjackson]

Almost there, just a few small tweaks.