Add support for alternative environment managers

[freakboy3742]

This is a work in progress; this should not be merged as is, and may be broken up into smaller contributions.

Adds:

• A uv environment management backend (Refs Provide the option to use uv instead of pip for creating environments and installation #2231)
• A conda environment management backend (Refs Support the use conda as a base environment for Briefcase apps #596)
• A pixi environment management backend Removed because Pixi integration needs more work
• Modifies the macOS, Windows, Linux and iOS platforms to use environment management for installing dependencies.

This is currently able to:

• generate development environments using all 3 environment backends;
• generate macOS apps using the Xcode backend using Allow for using a non-framework Python library. briefcase-macOS-Xcode-template#125
• generate macOS apps using the App backend using Add support for non-framework app builds. briefcase-macOS-app-template#104.
• generate Windows apps using the VisualStudio backend using Add extra default paths to PYTHONPATH. briefcase-windows-VisualStudio-template#105

TODO:

• Unit tests passing on macOS
• Unit tets passing on Linux
• Unit tests passing on Windows
• 100% Coverage
• Validation apps passing
• Validation apps added for conda

---

Key changes:

• App configurations gain an env_manager attribute, defaulting to venv (uv and conda also being legal values).
• There are new uv and conda VirtualEnvironment subclasses.
• The VirtualEnvironmentManager tool is now a mechanism for looking up the VirtualEnvironment class, rather than creating the venv.
• The VirtualEnvironment class (and subclasses) aren't used as a context manager. While shells have the concept of "activation" (which is a good match for context managers), that activation is really just setting some environment variables, which can be done on a per-invocation basis.
• Virtual environments identify if the environment is responsible for providing Python. This is to account for the fact that Conda/Pixi environments provide Python as a package, rather than needing a support package.
• There's a final install_managed_python_env() step when the environment provides Python; this is to copy the full lib folder into the app bundle. This is done instead of staging packages into an "app_packages" folder, and then "merging" them into a final location.
• The conda backend uses pip to install editable source and local packages
• The conda backend doesn't support universal apps or x86-64 on macOS. Given x86-64 support is almost EOL, the extra effort didn't seem worth it.

PR Checklist:

• I will abide by the BeeWare Code of Conduct
• I have read and have followed the CONTRIBUTING.md file
• This PR was generated or assisted using an AI tool