Improve plist handling

Nobody has claimed this yet.

This has been discussed but feels worth having a tracking issue.

There are a few different things going on here. I'll quote @madig on zulip:

>@cmyr thinking about better (embedded) plist handling, what we need is

>something that reads an entire file like fontinfo.plist, which has a rigidly defined key-value (type) schema, basically what serde excels at
something that handles kerning.plist and groups.plist which both have a defined structure but nothing else, like a simple special case of the fontinfo case?
something that handles lib.plist, which is a standalone, free-form plist file
something that handles embedded plists in .glif and layercontents.plist files
number 1 needs something that associates keys with types, number 2 is a basic parse-into-hashmap scenario and 3 and 4 need just be dictionaries that can take arbitrary plist key types plus values

- [ ] `fontinfo.plist`: The problem with fontinfo.plist is that it's huge, and has tons of optional keys, and so using serde to create a struct ends up both generating a lot of code and also creating this huge struct that must also be impacting binary size. It would be nice to replace this with some sort of typed dictionary, kind of like druid's `Env`.
- [ ] `lib.plist`: this probably doesn't need to change, and should just be a plist object. We might also want to expose API that lets people try and deserialize this to some concrete struct, if we want?
- [ ] embedded plists: this is mostly a matter of passing some portion of the xml off to a plist parser to generate a plist object, and then doing that in reverse when we serialize. It might also be nice to let the user provide some custom `serde`able type here, but it will be hard to make that play nice in the type system.

This all feels very doable; I'm going to start by testing out the tweaks to `fontinfo`, and seeing how that feels.

Start with the fontinfo.plist experiment described here and inspect how the existing plist and serde handling represents it. Then compare the requirements for lib.plist, embedded plists in .glif, and layercontents.plist. Done requires an agreed, tested scope for typed fontinfo data and the relevant plist parsing and serialization behavior.

Written by the indexing model from the issue text.