Better parity with macOS XML plist parsing

[korylprince]

This PR intends to bring this library in better alignment with macOS's plist parsing (e.g. plutil, PlistBuddy). This stems from some discussion on the MacAdmins Slack where MDM commands successfully parsed by this library were rejected by macOS's plist parser.

There's two commits:

• add a test suite of valid and invalid plists as determined by plutil -lint
  • if plutil is present in $PATH, the test will use the actual command to compare parse errors. Otherwise it will use a pre-baked list of invalid plists
  • this should make it easier to add similar test cases in the future if other issues arise
• clean up the XML parser by:
  • only allowing specific tags on for loops in parsing <plist>, <dict>, and <array> tags, so that extraneous tags or chardata returns an error like plutil does
  • verifying that all start tags are escaped with end tags, like plutil does

It should be noted that it's not possible to gain full parity with plutil. For example an malformed DOCTYPE like

<!DOCTYPE PUBLIC "-//Apple//DTD PLIST>

will be happily parsed by plutil, but Go's XML parser will go to EOF looking for the missing ", with no control to stop it.

However, this PR should bring us to much closer parity than we are now, and it seems to me it's better to have this parser be more stringent than plutil, instead of the other way around.

[korylprince]

Note: the original test used os.ReadDir and os.ReadFile, which failed the testers running Go versions older than 1.16. I force-pushed a version that uses ioutil's equivalents instead to appease the testers.

[jessepeterson]

Would this catch #3?

[korylprince]

Would this catch #3?

Yep, the testdata/xml/invalid-data.plist case matches #3.

[jessepeterson]

thanks @korylprince!