Add schema-serde streaming JSON/XML deserializers, ec2Query, Codec, and ClientProtocol

[pulimsr]

Adds response deserialization and the protocol-selection layer to the schema-serde runtime.

• ShapeDeserializer reworked to a push/consumer model (ReadStruct/ReadList/ReadMap), the dual of ShapeSerializer; scalars take const Schema&.
• JsonShapeDeserializer and XmlShapeDeserializer (new), CborShapeDeserializer updated to match.
• QueryShapeSerializer: full nesting + ec2Query flavor (new Ec2QueryNameTrait).
• Codec (Json/Xml/Cbor) pairs serializer+deserializer; ClientProtocol picks codec + content-type per protocol (restJson1, awsJson1.0/1.1, rpcv2Cbor, restXml, awsQuery, ec2Query),
  including the asymmetric query request/XML response case.

Check all that applies:

• Did a review by yourself.
• Added proper tests to cover this PR. (If tests are not applicable, explain.)
• Checked if this PR is a breaking (APIs have been changed) change.
• Checked if this PR will not introduce cross-platform inconsistent behavior.
• Checked if this PR would require a ReadMe/Wiki update.

Check which platforms you have built SDK on to verify the correctness of this PR.

• Linux
• Windows
• Android
• MacOS
• IOS
• Other Platforms

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sbiscigl]

summarizing from conversation:

so one thing that is left kind of ambigious to me in this is how we go from serializer to a hard type T. for instance given the class.

class bar {
std::string buzz;
};

class foo {
bar fizz;
};

how can the deserializer actually achieve constructing a object from {fizz: {buzz: \"value\"}}. would like to see a added test for each deserializer that accomplishes this, that can be used as the blueprint to adding it to codegen

[pulimsr]

Added nested foo{bar{buzz}} round-trip tests for all three deserializers in CodecTest.cpp

[sbiscigl]

summarizing from offline:

ok i think CreateDeserializer is where where we have the disconnect and where it will come together for us with "how do we actually create a object T". so looking at the smithy java codec. we're actually borrowing a little bit more than we need. and we can actually walk this back.

so Serialize looks good, lets park that lets only talk about deserialize

in the java impl the have one called deserializeShape that is closer to our needs and answers the second question which is "how do we construct T given a stream of characters".

javas looks like

public <T extends SerializableShape> T deserializeShape(byte[] source, ShapeBuilder<T> builder)

ours should end up looking like

void deserializeShape(const unsigned char* data, 
  size_t length,
  std::function<void (const Schema& schema, const StructMemberConsumer& consumer)> consumer)

this is so that during coden class would implement those struct member consumers to construct self

[pulimsr]

Done — ported from the smithy-java Codec you linked. Added DeserializeShape(data, length, SerializableStruct& shape), which delegates to shape.Deserialize(*CreateDeserializer(...)) — the analogue of deserializeShape(source, builder) → builder.deserialize(createDeserializer(source)). The generated shape implements From() as its member consumer to construct itself.

Two deltas from the sketch, both to match smithy-java:

• Kept CreateDeserializer public — smithy-java keeps createDeserializer as a core interface method and deserializeShape is a helper on top, so there's nothing to walk back.
• Passed the shape/builder instead of std::function<void(const Schema&, StructMemberConsumer&)> - that literal form is circular (the callback would receive the consumer it's meant to supply).