Add Embeddable type to store schema info for custom types

[lawmicha]

Issue #, if available:

Description of changes:

• This adds Embbeded protocol to return the schema information for embedded types. This means the code generated schema for an embedded type should look something like this:

class Category: Embedded {
...
}
extension Category {
    public enum CodingKeys: CodingKey {
        case name
        case color
    }
    public static let keys = CodingKeys.self

    // store info about the field's name, nullability, and their types.
    public static let schema = defineSchema { embedded in
        let category = Category.keys
        embedded.fields(.field(category.name, is: .required, ofType: .string),
                       .field(category.color, is: .required, ofType: .embedded(type: Color.self)))
    }
}

• Also introduced a .embeddedCollection case to hold embbeded types which are arrays. This was required when checking type at runtime.

    public var embeddedType: Embedded.Type? {
        switch type {
        case .embedded(let type), .embeddedCollectiion(let type):
           // the `type` here is always castable to the Embedded.Type. 
            if let embeddedType = type as? Embedded.Type {
                return embeddedType
            }

Testing done so far

• selection set verification
• graphql query variables input, graphQLInput
• sample app without conflict resolution enabled and making calls to API.create
• sample app with conflict resolution enabled and DataStore.save is successfully and is synced to the cloud

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[drochetti]

Overall I think the approach is mostly correct but we should not duplicate all the *Schema, *Field types we have for models.

We should either:

1. Extract that to a protocol and make it more generic
2. or use the ModelSchema, ModelField for the custom types as well and add a modifier saying it's not a model (or it's an embedded type)

[drochetti]

I think we need a better name for CustomCodable. ORMs typically call these "Embedded" types, maybe we could follow that?

@jpignata also mentioned the non-model thing we keep talking about is not clear, and I agree.

[lawmicha]

saw an issue (that doesn't seem critical to this PR) while testing, opening issue #541

[drochetti]

Looks good! I left a couple of minor comments, but overall it looks great :)

[drochetti]

update description.

also, maybe it would be good to expand on this a bit and explain the different between Embedded and Model

[drochetti]

you could potentially combine both using a , in the same if clause, or also use a switch where the default returns false.

[lawmicha]

i think if case .x = type, case .y = type is checking for both case and will never be true. not completely sure if that is the case when i saw a test failed, so i switched to using the switch statement instead

[drochetti]

minor: maybe worth considering calling the protocol Embeddable.

It suits well what the industry usually uses (see Hibernate approach) and also the iOS naming patterns.

An Embeddable is .embedded(type:) in a Model. I can see that making way more sense than "custom type" or "non-model type". =)

[lawmicha]

that sounds good, i will make this change!

[lawmicha]

related Codegen aws-amplify/amplify-cli#4545