Improve ease of use of api client in no_std

[haerdib]

After solving #279, with a no_std compatible Api, one could theoretically use the api-client with most features inside a no_std environment. But practically, a lot of workarounds are needed, because many types from substrate (Header, Block ,.. .) do not implement Serialize / Deserialize in no_std.

Improvement Ideas:

1. If parity allows it: Implement serde derivations also in no_std paritytech/substrate#12994
2. Provide most important types (Header, Block,..) with (de)serialization implementations, just like in Make Api no_std compatible #377
3. Do only enforce Serialization for types that are actually requested (for now, at least the full FrameSystemConfig is enforced, no matter what is actually requested via RPC) (not sure if that is possible, would need to be evaluated)

[haerdib]

Green light from parity, so lets try to go with 1.

[haerdib]

PR on parity side: paritytech/substrate#13027

[haerdib]

Marked as blocked. No response from parity for two weeks, even after asking further questions. Maybe we'll have to go for a different solution.

[haerdib]

So, the PR has been stalled once again for quite some time. So I guess it's time for a workaround, as I don't think the current solution is the way to go for much longer.

Ideas:

1. Rename the implemented substrate types to clearly distinguish between these types
2. For self implemented functions needing the serialization wrappers, we could map the types after serialization to the original substrate type and only then return it.

[haerdib]

Yey. Got once again an update from the Substrate side: paritytech/substrate#13027 (comment)

Seems like this will be a basic feature for them any ways, so there's a good chance that this PR will finally be accepted... eventually