Add REST response serializer, transparent content negotiation

Nobody has claimed this yet.

## Suggestion

We should...
1. Provide an extension point to allow contribution of response deserializers
2. Process automatic content negotiation to use the correct deserializer, similar to `BodyParser`.

## Use Cases

Currently, there is only support for `BodyParser`s that de-serialize REST request bodies to JSON. This means the Request-Response Lifecycle cannot be fully covered by a `BodyParser`, and requires lb4 users to manually serialize the controllers' response and prematurely return the response using `res.end` (see: #5168).

## Examples

For the extension point, a serializer could implement the following design:

```typescript
interface ResponseSerializer {
isSupported = (contentType: string) => boolean;
serialize = (body: any) => string
}
```

If need be, we can create a higher-level class the merges role of the existing `BodyParser` and the new `ResponseSerializer`. This has the benefit of requiring a single class to implement both serialization and deserialization. However, this adds complication to the LB4 design, and should probably be considered **after** implementing the `ResponseSerializer` extension point, so that the separation between the lower-level and higher-level extension points are clear. In the long-term, we may deprecate the lower level `BodyParser` and `ResponseSerializer` in favour of the "unified (de-)serializer".

## Acceptance criteria

TBD - will be filled by the team.

Start by reviewing the existing BodyParser extension point and the Request-Response Lifecycle, then compare the proposed ResponseSerializer interface with the content-negotiation requirements. The issue's acceptance criteria are still TBD, so completion requires agreed criteria covering serializer contribution, automatic selection, and response handling.

Written by the indexing model from the issue text.