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 

Previously we would rebuild this regex once per-part. We can instead
compile it once per-request.

Previously we would limit the number of multipart parts which were
files, but not other parts. In some cases this could cause parsing of
maliciously crafted inputs to take longer than expected.

[CVE-2023-27530]

Used to communicate a class of exceptions that represent 400 Bad Request
semantics.

Ruby 3.2 includes a cache-based regexp optimization, which is detailed
in https://bugs.ruby-lang.org/issues/19104. Which can speed up the regex
engine on many cases which would previously have resulted in a ReDoS.

One caveat of the implmentation is (quoting the issue):
> A bounded or fixed times repetition nesting in another repetition
> (e.g. /(a{2,3})*/). It is an implementation issue entirely, but we
> believe it is hard to support this case correctly.

Because of that limitation the RFC2183 regex was not previously able to
use that optimization and was not able to mitigate two recent ReDoS
CVEs.

This commit manually expands a `{2}` fixed repetition, which allows Ruby
3.2's optimization to take effect.

Before:

    > Regexp.linear_time?(/([0-9]{2})*/)
    => false
    > Regexp.linear_time?(Rack::Multipart::RFC2183)
    => false

After:

    > Regexp.linear_time?(/([0-9][0-9])*/)
    => true
    > Regexp.linear_time?(Rack::Multipart::RFC2183)
    => true

I want to make this change as additional hardening against possible
ReDoS attacks in this regex. At the moment I don't know of any which
are unpatched.

This commit fixes a ReDoS vulnerability when parsing the
Content-Disposition field in multipart attachments

Thanks to @ooooooo_q for the patch!

[CVE-2022-44571]