Isolate salt-pip's PYTHONPATH from the parent environment

[twangboy]

What does this PR do?

_pip_environment() in salt/scripts.py prepended salt's own extras directory onto whatever PYTHONPATH the calling process already had, rather than replacing it. Anything inherited there (e.g. leaked from an unrelated build/init process) stayed visible to salt's pip subprocess.

Combined with --force-reinstall, pip uninstalls whatever satisfies a requirement wherever it finds it on sys.path, not just in the target directory. An inherited PYTHONPATH pointing at an unrelated Python installation could therefore cause salt-pip to delete a package belonging to that unrelated environment.

PYTHONPATH is now set to just the extras directory by default, matching the isolation salt-pip already documents. Extras packages remain importable at runtime via the onedir's .pth file mechanism, which is independent of PYTHONPATH, so this doesn't affect normal usage.

Five new minion config options make this configurable rather than hardcoded, so a site can opt back into old behavior or lock salt-pip down further, instead of relying on every caller to pass the right flags by hand:

• saltpip_use_pythonpath (default False): restores the old prepend-onto-inherited-PYTHONPATH behavior for sites that specifically need it. Isolated behavior stays the default.
• saltpip_no_deps, saltpip_no_index, saltpip_disable_pip_version_check (all default False, i.e. unchanged behavior): force PIP_NO_DEPS / PIP_NO_INDEX / PIP_DISABLE_PIP_VERSION_CHECK on salt-pip's subprocess, so an operator can guarantee salt-pip never resolves dependencies, queries an index, or checks for a newer pip release. Implemented as environment variables rather than CLI flags, since salt-pip proxies arbitrary pip subcommands (list, show, uninstall, ...) and pip silently ignores these env vars on subcommands that don't use them, whereas the equivalent CLI flags would error out on those subcommands.
• saltpip_allow_find_links (default True, matching current behavior): --find-links is independent of --no-index by pip's own design (confirmed empirically), so saltpip_no_index alone doesn't stop pip from fetching via an inherited/leaked PIP_FIND_LINKS. Set to False to strip it as well. Kept as a separate, independent option rather than folded into saltpip_no_index, since --find-links alongside a disabled index is pip's own documented air-gapped-install pattern — forcing it off whenever saltpip_no_index is on would break that legitimate use.

Known, deliberately deferred gap: an inherited PIP_INDEX_URL / PIP_EXTRA_INDEX_URL is left untouched by every option here. pip already ignores both once PIP_NO_INDEX=1 is set, so stripping them in that case has no effect; filtering them when saltpip_no_index is off is a separate gap, documented as out of scope rather than addressed with more options (weighed against adding saltpip_allow_index_url / saltpip_allow_extra_index_url, which would be silent no-ops whenever saltpip_no_index is enabled — not implemented). Direct URL/VCS requirements (pip install https://..., git+https://...) also bypass --no-index inherently and can't be blocked by any pip flag.

Documentation updates:

• doc/topics/packaging/index.rst and salt/modules/pip.py: the pip execution module/state defaults to the same salt-pip / extras behavior on a onedir minion, how to target the system Python instead via bin_env, and an unsupported stop-gap procedure for patching a vulnerable bundled dependency directly.
• doc/ref/configuration/minion.rst and doc/topics/packaging/index.rst: all five new config options, including why the network options are env-var-based and the saltpip_allow_find_links / saltpip_no_index independence rationale.

Test coverage added:

• Unit tests in tests/pytests/unit/test_scripts.py and tests/pytests/unit/test_salt_pip_user.py covering the isolated-vs-opt-in PYTHONPATH behavior, each network-lockdown option, saltpip_allow_find_links (including that it's unaffected by saltpip_no_index's state), and each option flowing through salt_pip() end-to-end into the subprocess environment.
• Functional, onedir-gated tests in tests/pytests/functional/cli/test_salt_pip.py confirming installing a salt extension that depends on a package already bundled in the onedir doesn't duplicate it into extras, and that salt-pip doesn't see or touch an unrelated ("system") Python's packages even under --force-reinstall.

What issues does this PR fix or reference?

Fixes #70151

Merge requirements satisfied?

[NOTICE] Bug fixes or features added to Salt require tests.

• Docs
• Changelog - https://docs.saltproject.io/en/master/topics/development/changelog.html
• Tests written/updated

Commits signed with GPG?

Yes