Add UID handling with base tests

[headmin]

Add initial support for UID type in plist encoding/decoding

• Support UID type to handle unique object identifiers in binary plists, used by CoreFoundation Keyed Archiver.
• binary parsing, decoding, encoding, and XML writing logic to support the UID values
• very basic tests for UID marshaling

[jessepeterson]

Thanks! I'll take a deeper look later. I think the other folks did this a fair bit ago: DHowett/go-plist@e9d7568. Also DHowett/go-plist#54 is interesting and possibly related (and alternate encoding?).

On super duper quick glance I'd wonder about the specific UID type and instead supporting just using int64 reflection. But I need to go look closer. Thanks again! Do you have thoughts @korylprince?

[korylprince]

I gave this a full review and like the approach so far.

@headmin two things I'd like to see:

• XML decoder for the UID type/CF$UID dictionary
• a roundtrip test for XML (e.g. create a struct with a UID type, encode to bytes, then decode back to a type and verify it matches the original type)

@jessepeterson, I think a separate UID type is the right approach. That's how python does it. UID has special handling separate from a raw int/number, both in the binary and XML formats.

[headmin]

@korylprince added as requested, please have a look

[jessepeterson]

@jessepeterson, I think a separate UID type is the right approach. That's how python does it. UID has special handling separate from a raw int/number, both in the binary and XML formats.

Yeah thinking about it again this seems reasonable for encoding. Though you could have an additional field tag to indicate a more intricate type as an alternative strategy. For decoding I'm not convinced it makes much difference.

Separately the type naming doesn't quite seem consistent. UIDKind vs. UID doesn't quite look/feel like the rest of the code. But really more of a nit than anything.

[headmin]

@jessepeterson you can review again

[korylprince]

LGTM, not sure if @jessepeterson still wants to review.