Update RBS for Rack

I am currently tinkering with Rack and RBS, using this collection for Rack’s RBS. Unfortunately, it is quite lacklustre. It looks like it was partially prepared by @mame and TypeProf through #36 and never touched since.

• This RBS document demands a good amount of polishing to be successful.

I’ve inquired about Rack’s opinion on developing RBS themselves through rack/rack#1967. In summary, their consensus is that RBS’s benefits aren’t significant enough to justify the labour of coercing Rack’s duck types to RBS’s static typing. In that discussion, I highlighted: [Update: #232 covers this blockquote]

However, it has possible mistakes and undocumented fields. Examples from Rack::Response alone:

• The attribute Rack::Response#body should probably follow the SPEC § The Body, but the RBS restricts it to one or an Array of Rack::Lint or nil.
• I’ve been working around the above with Rack::Response.[], whose args are untyped in the RBS.
• Rack::Response#each is also missing RBS of &block.

[Significatly modified section starts]

• Besides filling in the blanks, note that Rack just got a new major version recently (Rack 3). Regarding the leap to Rack 3, a question yet to be answered is if we, as third-party volunteers, should attempt to catch up with Rack’s development (without publishing unusable snapshots) or simply freeze at Rack 2. Keep in Mind that a complete RBS of Rack doesn’t provide a unique convenience (yet) perhaps besides pocke/rbs_rails#174, especially since Rack’s YARDocs and Rack::Lint already detail acceptable types (static or duck) equal to or better than a set of RBS could.

Start by reviewing the existing Rack RBS produced through #36 and the Rack::Response examples in the issue, then read rack/rack#1967 for the project's position. Clarify whether the collection should target Rack 2 or Rack 3 before changing the signatures; completion criteria are not defined beyond broadly polishing and filling gaps in the RBS.