Hardcoded IO in generated code

Context: https://softwaremill.community/t/how-best-to-go-about-proposing-and-helping-with-code-generation-improvements/542

Tapir version: 1.13.19

If you have a lazy type (eg, a default binary octet stream) specified as the body, the code generator sets up an fs2 Stream, as it should. Unfortunately, it hardcodes the effect of that Stream as IO.

That's often correct, but if you're in an environment that is trying to be effect-neutral (as our services are), it's basically unusable. We're admittedly a little unusual in following tagless final in services, but this problem would be a blocker for any library that follows Typelevel best practices. (And heaven knows I've written my share of libraries that were built around an external OpenAPI spec.)

For now, I've hacked our first OpenAPI spec to require the incoming file to be defined as an eager String, but that's pretty awful -- counter to both Tapir's and our own architectural best practices.

I think what I'm hoping for here is a feature flag that causes the generated code to be abstract in F[_], so that it plays nicely in a tagless-final environment. Does that seem appropriate? I'm happy to work on this, if so.

No file or test is named. Start at the OpenAPI code-generation path for lazy request bodies and trace where the fs2 Stream effect is fixed to IO; done means generated code can preserve an abstract F[_] under the proposed feature option, with coverage for that case.