fix: preserve raw request bodies for custom content types

[mikemikimike]

Summary

• Closes Pass binary payloads to decode_request unchanged #732
• Preserve raw request bodies for non-JSON, non-form content types.
• Add a regression test covering binary payloads.

Implementation

Requests with `application/json` (including `+json`) continue through JSON decoding, and form/multipart requests keep their existing behavior. Other request content types now use FastAPI's `Request.body()`, allowing `decode_request` to receive the original bytes unchanged.

Compatibility

Existing JSON and form/multipart request handling is unchanged. Custom content types that previously failed JSON parsing now receive raw bytes.

Tests

• python -m compileall -q src/litserve/server.py tests/unit/test_request_handlers.py — passed
• git diff --check — passed
• pytest tests/unit/test_request_handlers.py -q — not completed: the uv-managed environment remained silent/hung during dependency setup/import in this Windows environment; the process was stopped.
• Docker checks were not run; this change does not require external services and the repository provides no Docker test configuration.

[mikemikimike]

Maintainer feedback requested: exposing Content-Type to decode_request

This PR now preserves raw request bytes for custom content types and covers JSON, +json, charset parameters, and form/multipart compatibility.

One part of #732 remains an API design question: decode_request receives the raw bytes, but it does not receive the original Content-Type. For protobuf and other content-type-specific decoders, callers may need that metadata.

Could maintainers confirm the preferred follow-up/API shape?

• pass a request/context object containing both body and headers;
• add an optional context parameter to decode_request; or
• intentionally leave content-type handling to the endpoint/API implementation.

I have not introduced a new API in this PR to avoid guessing at a compatibility-sensitive design.