Not strictly necessary, but this limits the damage in pathological
cases.  These limits are probably already too generous, we could
probably get by with 8 params and 1024 bytes.  One of tests uses
more than 1024 bytes, though.  Still, it seems unlikely any
legitimate requests would exceed these limits.  We could make the
limits configurable via an accessor method, if desired.

Use BINARY for this, as we do for multipart encodings.  Extract a
find_encoding method for this.

The ReDoS fix in ee25ab9a7ee981d7578f559701085b0cf39bde77 breaks valid
requests, because colons are valid inside parameter values.  You cannot
use a regexp scan and ensure correct behavior, since values inside
parameters can be escaped.  Issues like this are the reason for the
famous "now they have two problems" quote regarding regexps.

Add a basic parser for parameters in Content-Disposition.  This parser
is based purely on String#{index,slice!,[],==}, usually with string
arguments for #index (though one case uses a simple regexp).  There
are two loops (one nested in the other), but the use of slice! ensures
that forward progress is always made on each loop iteration.

In addition to fixing the bug introduced by the security fix, this
removes multiple separate passes over the mime head, one pass to get
the parameter name for Content-Disposition, and a separate pass to get
the filename. It removes the get_filename method, though some of the
code is kept in a smaller normalize_filename method.

This removes 18 separate regexp contents that were previously used
just for the separate parse to find the filename for the content
disposition.

Fixes #2076

- Fixes #1968 

An alternative approach would be using a single string inside an array
and appending to that.  This approach is more backwards compatible,
but results in more memory usage.

Fixes #1957

https://rubygems.org/gems/rack/versions says 3.0.4.2 was released March 02, 2023

[ci skip]