Since 'private' means "limit to the enclosing scope (and extensions
thereof)", putting it on a member means that the member can't be
accessed everywhere the type might show up. That's normally a good
thing, but it's not the desired effect for synthesized members used
for derived conformances, and when it comes to class initializers this
actually violates AST invariants.
rdar://problem/39478298
* Introduce diagnostics that explain why derivation of
Encodable/Decodable fail rather than just silently failing
* Allow properties with default values to be omitted from CodingKeys
enum and from encoding/decoding
* If `CodingKeys` is a typealias, reach through it more consistently to
get at the final target type
* Add unit tests to confirm this new behavior for classes and structs
NOTE: Although this made the diff bigger, standalone variables named
"type" have been renamed to "target" throughout, since the word "type"
may be ambiguous and makes debugging impossible. "target" is unique.
* Allow CodingKey conformance to be automatically derived for enums
which have no raw type (with no associated values) and which have
a raw type of String or Int.
* Allow Encodable and Decodable conformance to be automatically derived
for classes and structs with Encodable/Decodable properties
* Add initial unit tests for verifying derived conformance
