Incorrect package summaries when scanning the React GH repo

### Description
Scanning the react https://github.com/facebook/react/archive/v16.7.0.tar.gz returns weird results.

Several packages are returned based on "package.json" files but most of them are actually
test data files and NOT real packages such as in https://github.com/facebook/react/tree/master/fixtures ...
therefore they do not exist as published real packages and the inferred download URLs are not correct.
Things such as https://registry.npmjs.org/attribute-behavior/-/attribute-behavior-0.1.0.tgz yield a 404.

Beyond improperly reporting these fake test "fixtures" packages
(that should/could be skipped or at the minimum should be set in a "test" facet),
the other issue is that the root package.json is not detected correctly.
This root package.json has no `name` attribute which is weird and uses the
rare `"private": true,` attribute meaning it never meant to be published on the public registry...
and furthermore its version is not correct https://github.com/facebook/react/blob/v16.7.0/package.json as the root package.json contains something else.

So we have a repo that has:
1. tests data mistaken as packages
2. no correct top level package information
3. actual published are packages nested below it in https://github.com/facebook/react/tree/v16.7.0/packages
This is a kind of "monorepo" using yarn "workspaces" https://yarnpkg.com/blog/2017/08/02/introducing-workspaces/

To compound the issue this version was never pushed as-is to the npm registry.
Instead they pushed this https://registry.npmjs.org/react/16.7.0 ...
which has this version 0.0.0-4a1072194 and download https://registry.npmjs.org/react/-/react-0.0.0-4a1072194.tgz ...
4a1072194 is the short form git commit hash for the `v16.7.0` tag.

In this case, may be we should use the fact this is a download from a github release instead and treat this as a package type `github`? But we cannot really know this just from code tree itself.

Basically there are many ways to get confused and we these would likely help:
- possibly still report a partial top level private package and its dependencies
- filter out or facet the fixtures
- make sense of the "workspace" Yarn feature we have here