[hsjs] Tracking issue: rework request/response serialization system.

The current serialization systems are very confusing and buggy. This issue tracks the other issues involved in reworking the request/response serialization system:

- https://github.com/microsoft/typespec/issues/3780
- https://github.com/microsoft/typespec/issues/6375
- https://github.com/microsoft/typespec/issues/6376
- https://github.com/microsoft/typespec/issues/6787
- https://github.com/microsoft/typespec/issues/6818
- https://github.com/microsoft/typespec/issues/6932

My view and rationale for combining these into a single tracking issue is that I believe these are all solved by a single unifying rework around how request/response data are treated that starts with the handling of interfaces and operations.

- Implement **effective transforms** for operations using mutators. These transforms will apply shape changes due to visibility transforms, encoding degenerations (e.g. "I don't know how to encode this property in this manner, so I represent it as the target type instead"), and preferential representations of TypeSpec types ("when `bytes` is the body of a request, it can be a stream instead of a buffer; the type of a `@multipartBody` property should be represented as a stream of parts instead of a record or array; the names of "unspeakable" properties should be changed if doing so will not conflict with other properties in the model").
- Unify all body serialization/deserialization logic based on the "disposition" of the body (request, response, multipart), like the HTTP core library does.
- Construct the logical types that represent request/multipart payloads in a single pass from a function that has access to [a] the fundamental body type (see #6932), [b] the parameters extracted by the router, [c] the request context (headers, query params). Serialize the logical types that represent response/multipart payloads in a single pass inversely.