CodingKeyPath: Add support for Encoding and Decoding nested objects with dot notation

[xwu (Xiaodi Wu)]

@anandabits

there is a broad set of challenges we face when working with serialization formats outside of our control

@Alejandro_Martinez

Codable is amazing when you have full control of the situation, but it's still far from ideal when dealing with the ugly real world APIs

Recall the stated aims for Codable:

• It aims to provide a solution for the archival of Swift struct and enum types
• It aims to provide a more type-safe solution for serializing to external formats, such as JSON and plist

Obviously, these facilities may also be useful for ingesting JSON that's not serialized from Swift models but from other sources. But a design that is capable of dealing with arbitrary third-party APIs requires a degree of extensibility and configuration significantly beyond what's necessary or most usable for the stated primary aims.

There's obviously no need to make it unnecessarily difficult to work with third-party data that happens to be well behaved. However, when it comes to formats that would require a whole laundry list of additional features to be added to Swift, I think it's worth thinking carefully about the intended scope of the problem that Codable is meant to address (i.e., what features we should add to Codable) versus something that's altogether different (i.e., a separate set of facilities, perhaps even an entire library).