util: avoid quadratic whitespace scan in MIMEType parser

[uwezkhan]

The MIME parser trims trailing HTTP whitespace from the subtype, the parameter list, and each parameter value by searching against the unanchored regex /[\r\n\t ]*$/. String.prototype.search restarts that match from every offset, so a long run of internal whitespace makes each trim O(n^2). The run is reachable from untrusted input through the public util.MIMEType API and through data: URL parsing, e.g. new MIMEType('text/plain;x=a' + ' '.repeat(60000) + 'b'), which is a quadratic-blowup ReDoS.

Replacing the three searches with a backward whitespace scan returns the same start-of-trailing-whitespace index in linear time. Keeping the bound in the parser rather than asking callers to pre-trim matters because the constructor, the lazy params parse, and the value parse all funnel through the same trim and consume that index identically. The helper is a few lines longer than the regex constant in exchange for dropping the quadratic factor; parse output is unchanged, verified equivalent to the old regex over 300k random inputs.

Before vs after, same 60k input:

before: util.MIMEType parse blocks the event loop ~8000ms
after:  ~0.03ms, same as a benign 'text/plain;x=ab'