Multipart decoding using EntityDecoder

[IndiscriminateCoding]

This PR is an attempt to improve multipart decoding by allowing to use EntityDecoder on a Part[F]:

1. It introduces new interface Media[F] which is implemented by Message[F] and Part[F];
2. EntityDecoder.decode now accepts a Media[F] instead of Message[F].

[rossabaker]

I think this is neat.

@ChristopherDavenport has long advocated for a typeclass approach to Message, and I'm guessing he won't like this. But the concept of Media might be a typeclass for which Request and Response and Part have instances.

I think the typeclass approach may be still compelling, but this makes a currently awkward thing less awkward, so I like it.

Test failure is legit

[rossabaker]

I'm so numb to the flaky tests that I didn't notice there's a tut failure here. We would need to clean that up first.

[IndiscriminateCoding]

Fixed

[ChristopherDavenport]

Leaving a message that this concept digs further into a well I'm uncomfortable with. This is more unbound inheritance. Making it harder to go the other direction.

[IndiscriminateCoding]

@ChristopherDavenport another approach (without resorting to inheritance) would be to make Media a case class and store it in a fields of Request/Response/Part. But that would be more invasive change (and less efficient).

[rossabaker]

#1572 represents the typeclass approach. The diff is unfortunately difficult to read after I did something catastrophically stupid while working on docs, but the comments show the mostly pros and a few unresolved cons. I also think the typeclass approach might help with things like AuthedRequest, which I don't think was appreciated during the discussion of #1572.

I think the alternative to this PR is to have Media be a typeclass, like Message in #1572.

In either case, it would be nice if we had something that works for Part. The status quo is insufficient.

[IndiscriminateCoding]

Not sure if I like the (lawless) typeclass approach, tbh.
Basically you can just replace this typeclass with a bunch of lenses.
But (IMO) http4s API is already pretty complex (which is the price of MTL-like design).

[rossabaker]

Would be nice to decide on this before 0.21 final, but are just looking at a milestone today.

[hamnis]

I think this is reasonable and we should add this.

[rossabaker]

Between the two styles proposed, I come down on the side of working code. Someone can try the typeclass proposal after 0.21.