Input object null vs undefined

[NeedleInAJayStack]

This adds support to differentiate between explicitly providing the literal value null and implicitly not providing a value at all, as described in the spec here and here.

To do so, an undefined case is added to the Map enum, and argument parsing uses this value when expected arguments are not provided. Field default values now override only undefined maps.

The end result is that Map encoding works like JSON where a field with a literal null is contained by the decoding container, whereas an un-provided value is not. From here, custom object decodings can adjust functionality based on the two situations. For example:

struct Obj : Codable {
    let field1: String

    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        
        if (!container.contains(.field1)) {
            field1 = "I was not provided"
        } else {
            field1 = try container.decode(String?.self, forKey: .field1) ?? "I was provided, but null"
        }
    }
}

[paulofaria]

@NeedleInAJayStack great work! We really needed this.

[paulofaria]

Everything looks good to me. Would be nice to check for other instances of Map? elsewhere in the codebase and reason if using undefined would make sense. I was reluctant about adding an undefined case before, but now I think we should've had it all along.

[NeedleInAJayStack]

@paulofaria I removed the OrderedCollections import and removed the ubuntu-16.04 CI because it's been removed. Mind approving again after these changes?

[paulofaria]

Done!

[NeedleInAJayStack]

@paulofaria Argh, since the ubuntu 16-04 test started and never completed, I can't merge it (even though I removed it for the future). If you could merge, I'll tag and release!