add EXTERNALLY-MANAGED

[jaimergp]

Closes #1

In this PR, we are implementing the following behavior:

• conda-pip packaged files include EXTERNALLY-MANAGED by default. This protects the base environment (or whatever conda-pip has been installed to; usually base).
• On target environments, we will place EXTERNALLY-MANAGED after conda pip -p target install ... executions.
• Thanks to a post-command plugin:
  • We will also inject EXTERNALLY-MANAGED if the target environment has pip.
  • In Python updates, the plugin will also migrate the file from one lib/pythonX.Y directory to the new one.
  • We will remove the marker file when pip is not present in the target environment anymore.
  • This is not done in envs created by conda-build, or if conda-pip is present in base as a dependency and not explicitly installed (we check the history file for explicit presence of conda-pip).

To do / discuss:

• What happens when conda remove --all is invoked? This should be caught by the post-command plugin anyway, but a few empty directories might be in place? Maybe conda clears the tree? Investigate.
• Same but for conda env remove.

References:

• https://peps.python.org/pep-0668/
• https://packaging.python.org/en/latest/specifications/externally-managed-environments
• https://docs.python.org/3/library/sysconfig.html#sysconfig.get_paths

[jaimergp]

I'm not too sure yet about writing the files directly to the target environment. It creates the opportunity for lingering files unless the user removes packages nicely. Maybe an alternative is to inject a fake conda-meta/externally-managed-1.0-py3xy.json metadata file that lists the EXTERNALLY-MANAGED file so it can be conda removed nicely. I'll leave that for a further issue.

[jaimergp]

Pinging @jezdez @pradyunsg for awareness / comments if time allows :)