Add support for using conda as an environment manager.

[freakboy3742]

Adds support for using Conda as an environment manager.

Adds one major new concept - the idea that the environment manager can be responsible for providing the Python install. When using Conda, there's no "support package" to install; Conda provides libpython, and the full Conda environment is copied into the application bundle as the last step of the install.

It's also assumed that if the environment is providing Python, Python packages are installed into that environment; so on update, updating the support package or the requirements requires rebuilding both.

Conda environments can only be used for macOS and Windows. A Conda doesn't have support for iOS or Android (yet... see this draft CEP); and a Conda environment can't be included as a Linux system package because it includes libraries (like libssl) that get flagged by DEB/RPM auditing tools. It might be possible to build a Flatpak that includes conda, but that is deferred from this PR.

On macOS, Conda cannot build universal apps; Conda binaries are single platform, and merging entire Conda environments would be complicated at best. As x86-64 macOS support is nearing EOL, I've decided to avoid the complication.

Add env_manager = "conda" to a project to test this configuration.

Building on macOS requires the use of custom templates:

• Allow for using a non-framework Python library. briefcase-macOS-Xcode-template#125
• Add support for non-framework app builds. briefcase-macOS-app-template#104

macOS requires a different stub binary for "framework" builds (which use the support package and Python.xcframework) vs "non-framework" builds (which use Conda and libpython3.X.so).

Building on Windows requires the use of custom templates as well:

• Add extra default paths to PYTHONPATH. briefcase-windows-VisualStudio-template#105
• Add extra default paths to PYTHONPATH briefcase-windows-app-template#112

I've preemptively published an experimental stub binaries (build x2917) to allow testing the macOS and Windows app templates. The app templates uses these stub binaries. The Xcode/VisualStudio templates can be merged today; once that happens and this PR is merged, the stub binary will need to be formally tagged, and the app template updated to use that new stub.

This PR also includes documentation for the general topic of environment management, and normalises the naming of the venv backend (renamed from std_venv - I realized the reason it was causing headaches was the .gitignore file).

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

[mhsmith]

Why is this option in the project section, which otherwise only includes high-level metadata? Could it be in the application section instead?

I remember we named requirement_installer_args on the assumption that when we later added this option, we would call it requirement_installer. I wonder if that might still be a good idea, because what the developer is really interested in is requirements, and environments are only a means to that end.

The only exception is that Conda also provides Python itself, but I think that's a relatively minor detail compared to the clarity advantage of requires, requirement_installer and requirement_installer_args all having similar names, and appearing next to each other in the documentation. This would also remove any implication that uv is used to provide Python, which is a common use case but not one we currently support.

In that case, we would presumably rename venv to pip, at least in the the user-visible option.

(Remainder moved to beeware/beeware-docs-tools#262)

[freakboy3742]

I put it in the project section because it can be specified at the project level - which would seem to be the most likely usage as well - you're unlikely to use conda for one app, and uv in another app, inside a single project.

As for requirement_installer - I see what you're driving at, but nobody thinks of uv or conda as a "requirements installer" - installing requirements is just one of the things you do in the environment. Granted, from the perspective of Briefcase, it's the most important (and almost the only) thing you do - but in the case of conda, its explicitly not just the requirements installer.

The overflow on names is something for the theme; I presume a different overflow behaviour is possible, but I'd need to dig into it.

[freakboy3742]

Update:

• I've merged the Windows Visual Studio template, and tagged new binaries
• I've updated the Windows app template to use the new binary.
• I've merged the macOS Xcode template. I can't tag new binaries until this PR lands.
• I've updated the documentation to include the points flagged in reviews to date - mostly details of usage and edge cases
• I've merged with main, to pick up the fixes cases that caused issues during dependabot.