Fix controller @Body Object parameters

[yawkat]

There's two bugs here.

Let's consider the following cases:

1. application/x-www-form-urlencoded, @Body Object param (tested by the old FormDataDiskSpec)
2. application/json, @Body Object param (prev. no test, tested by a new TCK test)
3. application/x-weird, @Body Object param (prev. no test, tested by a new netty-specific test)
4. application/x-weird, @Body MyRecord param (prev. no test, tested by a new netty-specific test)

Prior to 4.6, case 2 has a registered "normal" reader (the JSON reader) that can handle this case fine, the other three cases do not have readers and rely on fallback conversion logic. Forms have some special handling here.

In 4.6, the way raw type readers (e.g. that for String) were resolved changed. This means that for Object params, all raw type readers were now eligible, since they can read a subtype of Object (e.g. String). For cases 1, 3, and 4, this is a breaking change, since the reading is now done by a (random) raw type reader, instead of falling back to conversion logic.

This change broke the FormDataDiskSpec (case 1). To fix this, 1d09d95 introduced a check that would blanket-ignore the reader for all Object-typed params, falling back to the conversion logic. This fixed cases 1 and 3, but inadvertently broke case 2, since the JSON reader was also ignored.

Case 2 is apparently common enough that there have been multiple reports about it. It also exposed the second bug, a double-claim of the body, which is a fairly simple fix. But it shows that the fallback conversion logic had no test coverage, since this bug should trigger reliably. That is what BodyConversionSpec is there to improve.

My proposed fix is to make the raw message readers not apply to Object parameters, and to remove the band-aid fix from 1d09d95 that broke case 2.

Fixes #11266