improving package tree realization.md

grab bag o' goals:

• as much as possible, have a package tree produced with just the facts – no linting, only warnings or errors because there's stuff in there that's flat-out wrong
• follow the Node module resolution algorithm's rules for determining what looks like a module (which may end up including things that aren't packages)
• produce the list of warnings about the state of the package tree and the printable tree for npm ls during a single pass through the code
• split apart normative and descriptive scans of the package tree
• unify read-package-json and normalize-package-data because the split between them is more an accident of history than a consequence of design
• split validation / linting checks in unified read-package-json + normalize-package-data out into an independent package that operates on a realized tree
• use the above to support an npm lint command
• get closer to having a standalone npm-install package