Surface more information about the package on the website (and optionally from the cli, after install)

[fluffynuts]

There are a few reasons why someone might try out a package and then move on to something else, but here are some fairly big ones that I've encountered recently:

1. The package has moved or been renamed and the old location can't be updated for some reason - or perhaps there's a compatible replacement/fork. xmldom is a great example - it's moved to @xmldom/xmldom, but the consumer only finds out about this after an npm audit fails (or dependabot sends a message), and they have to be savvy enough to go hunt down this information at github. I got dependabot alerts and it took me a while to find out that I couldn't update xmldoc because it's essentially deprecated in favor of @xmldoc/xmldoc.
2. The package uses native modules which can fail to build at the target for any one of many reasons (personally, I'm trying very hard to avoid native modules because eventually they come back to cause me a major pain in my rear-facing end - it feels ridiculous that to be able to run some Javascript, I have to have a full installation of Python (at some point, it had to be py 2 as well, so I had multiple versions installed and had to play tricks with pathing) as well as the platform sdk and a C/C++ compiler. A small JS repo suddenly needs a lot more to support it and has a lot more reasons why it could work for me but fail on someone else's machine. Cross-platform code is harder to maintain too.

1 (and, to some extent) 2 could possibly be solved with an implementation of "Community Notes" like social media sites. Curation is a problem which would need solving, but if I had seen upfront that xmldom had moved, I wouldn't have wasted the time using it and then the next day having to switch it out (and thankfully, it was a drop-in replacement even though the version has gone up quite a bit - otherwise there would have been wasted time as I port away from the old api to the new one)

2 could be achieved at upload time - having a big "USES NATIVE MODULES" marker would be (for me, at least, perhaps others) incredibly helpful, because I'd know to look elsewhere first to perhaps find a good-enough js module. This scan should include the entire dependency tree because I may install something which depends on, eg, xml2json and think everything is working fine because I've been lucky enough to have a build happen on my machine in the flurry of output from npm cli, but the moment this gets to a machine with a different OS, things break.