rpc: Decide who is responsible for emitting "normalized" json

At present the arti-rpc-client-lib code forwards Json replies as string, without normalizing them in any way. This is fine if we assume that Arti already emits Json strings that are normalized to the client's taste, and/or if we assume that Arti and arti-rpc-client-lib will always use the same json code (serde_json) but possibly we don't want to make those assumptions.

At !2258 (comment 3048543), @Diziet says:

One design question I have:

Should we be

1. Inspecting the message from Arti, to find the information we need (id; kind of response), and then forwarding the response text in the original JSON fork to our client?
2. Reconstructing a fresh JSON string from fully deserialised data (serde_json::Value).

In principle doing (1) risks JSON parsing ambiguities/disrepancies resulting in anomalies, or possibly even vulnerabilities, where arti-rpc-client-core interprets the JSON differently to the calling application's JSON library. The downsides of (2) are that you can't pass strange stuff through from Arti to the client (which is actually an advantage, I think) and the perf implications which I think oughtn't to be a concern here.

So I wonder if we should do 2 instead. That would change all three of these Response types.