doc: add policy for “placeholder” executables

Split off from #51994.

I don’t think we want our distribution to include or create upon installation “placeholder” executables: a command like yarn that downloads and installs Yarn when run. This is for the following reasons:

• It’s already very easy for users to install CLI tools, whether via npm install or curl or the command of their choice.

• Providing placeholders puts us arguably on the hook for any security issues contained within the placeholder. Even if we have some fine print somewhere saying that somehow we’re not responsible for any vulnerabilities within the Yarn software that our yarn command downloads and installs, I think many users would understandably argue that that doesn’t absolve us: that we should provide the same security guarantees for Yarn that we do for npm, even if Yarn isn’t actually bundled within our distribution.

• Any placeholder we provide would arguably need to follow the same rules for breaking changes that we currently follow for npm. So if a yarn placeholder currently downloads Yarn 1, it can’t be changed to download Yarn 4 until the next major release of Node. That would mean that Yarn would need to coordinate their major releases with us the way npm does, to minimize lag time; and it would also mean that we can’t ship a placeholder that simply always downloads the latest version. Such “pinned” placeholders, whether pinned to an exact version or the latest version of a semver major line, are much less useful to users and provide worse UX than current methods for installing software.

• Placeholder executables arguably serve a “political” purpose: they imply a recommendation of the referenced software. Just as bundling npm arguably implies a recommendation of npm, shipping placeholders implies equivalent recommendations for those other tools. Obviously this is desirable for competitors to npm, but I don’t think this is a road we as a project want to go down: it’s much easier to state that we’re agnostic and don’t have recommendations for any tools, rather than having debates about every tool that someone proposes to create a placeholder for.

Landing this PR would mean that we’re deciding not to land https://github.com/nodejs/node/pull/51886 or https://github.com/nodejs/node/issues/51931 in the near term, and that any future efforts at either of the proposals in those PRs would require updating the text added by this PR with a new policy to permit the placeholder executables envisioned by either of those PRs.