add web app manifest parsing gatherer

[brendankenny]

@paullewis

• some changes were made to the parser to retain more information through the manifest parsing. Each node in the manifest tree retains its original raw value, the parsed value, and the "developer warnings" the spec specifies when you make a mistake, even when recovered. The spec is very forgiving, though, so I've tweaked some things to make sure they still work even while issuing a warning. The original linear _logs is dropped in favor of the warning being associated with the erroneous manifest entry.
• changes from above mean that at every item in the manifest you have to hit .value to get the parsed value of that node. Kind of annoying, open to ideas there. See changes to test for example.
• ported tests from https://github.com/mounirlamouri/manifest-validator/blob/master/test/manifest-parser-tests.js. They are very preliminary.
• added gatherer that executes js in the page context to have the page pull in the manifest itself while we figure out artifact: parsedManifest #22
• nothing is actually audited yet. Value of parsed manifest is on data.parsedManifest inside your friendly neighborhood auditor

[brendankenny]

as stated here, planning on bringing in e.g. devtools frontend color parsing code rather than dragging in all of jsdom just to do some color parsing code

[brendankenny]

in theory this gatherer could collect all the functions that need to run in the context of the page itself (e.g. the one in viewport-meta-tag/gather.js), but long term (as we think about extensibility) it may be too hard to guarantee that these scripts don't step on each other

[samccone]

move from helpers => parsers

I can see the need in the future for multiple parsers