feat: add network diagnostic check

[WillieRuemmele]

What does this PR do?
adds a few network checks to verify the users machine can access

yarn/npm registries

What issues does this PR fix or reference?
@W-15758164@

[mshanemc]

QA notes:

✅ works

📓 https://registry.npmjs.org vs. https://registry.npmjs.org/ no big deal, probably better to take their env/config "as is" rather than try to clean it up

pass - can access: https://registry.npmjs.org
pass - can access: https://registry.yarnpkg.com
pass - can access: https://registry.npmjs.org/

💡 I see that the diagnostics for PDR and auth identify themselves like

warn - [@salesforce/plugin-deploy-retrieve] sourceApiVersion matches apiVersion
fail - [@salesforce/plugin-auth] CLI supports v2 crypto

Maybe plugin-trust should call addPluginData like https://github.com/salesforcecli/plugin-deploy-retrieve/blob/eaf7a2bc7d38fc6e58f39ff821da2d4d97960baa/src/hooks/diagnostics.ts#L59-L60

[mshanemc]

QA notes (sad paths)

npm_config_registry=https://google.com

fail - can't access: https://registry.npmjs.org
fail - can't access: https://registry.yarnpkg.com
fail - can't access: https://google.com

I think that's somewhat misleading (maybe just change the output text?)

1. the environment can totally access it. It's more of it not responding with the correct reply (assuming npm expects something that a registry would give back)
2. the presence of the env is impacting the npm.ping that the test uses, so that they're all picking up npm_config_registry=https://google.com and not what they say the problem is?

---

💡 suggestions...what if we told people to run npm ping from their environment so they "replicate" that problem, too?
💡 what if we told them about the environment variable we found or are using?