[3.15] gh-149819: fix .pth and .start file processing in subprocess when inheriting...

[3.15] gh-149819: fix .pth and .start file processing in subprocess when inheriting PYTHONPATH (GH-150177) (#150202)

gh-149819: fix .pth and .start file processing in subprocess when inheriting PYTHONPATH (GH-150177)

* gh-149819: Fix .pth files not loaded in Python subprocesses

After PR gh-149583 (Fix double evaluation of .pth and .site files in
venvs), .pth files are no longer loaded in subprocesses started with
subprocess.run([sys.executable, ...]).  The root cause: main() seeds
known_paths from removeduppaths() with all sys.path entries inherited
from the parent process.  addsitedir() then skips .pth processing for
every directory already in known_paths.

Fix:
- main(): call removeduppaths() for dedup but start known_paths as a
  fresh empty set, so that addsitedir() processes .pth files in every
  site-packages directory regardless of inherited sys.path.
- addsitedir(): move known_paths.add() before the sys.path.append and
  guard the append with 'sitedir not in sys.path' to avoid creating
  duplicate entries when called with a fresh known_paths.

This preserves the gh-75723 dedup guarantee while allowing subprocesses
to load .pth files.

* Fill out the tests for GH#149888

* Extend _make_start() and _make_pth() to take an optional `basedir` which is used instead of
 `site.tmpdir` if given.
* Add test_pth_processed_when_sitedir_already_on_path() to test the core GH#149819 bug: .pth files
  in subprocesses aren't handled if PYTHONPATH pointing to the .pth directory is inherited.
* Similarly add test_start_processed_when_sitedir_already_on_path() to verify that .start files in
  the same circumstances are also now processed.

* Update Lib/site.py

* Oops!  Remove redundant code

---------
(cherry picked from commit 3c298e2e385fc6f462abaada2fd680deb1a2b58e)

Co-authored-by: Barry Warsaw <barry@python.org>
Co-authored-by: BugBounty Mind <bugbounty-mind@deepseek.tui>
Co-authored-by: scoder <stefan_ml@behnel.de>