Support the use conda as a base environment for Briefcase apps

There is a significant part of the Python ecosystem (especially in the science/data space) that uses Conda to manage their Python environments. Some tools are easier to install via Conda; it therefore follows that some apps may benefit from being based on a Conda environment, rather than the default "vanilla" Python installation.

Briefcase should provide, as an option, the ability to build the app on a Conda base environment, rather than the "vanilla" Python install.

This will involve providing a configuration option in `pyproject.toml` to specify the base/foundation that an app wishes to use (with the current "vanilla Python" behavior being the default); then, depending on the configured foundation, Briefcase should change:
1. The default application template
2. The default support package
3. The tool used to install app packages

Ideally, this would be done via a plugin interface, so that:
1. The conda backend can be developed independently without imposing a maintenance burden on the briefcase team
2. Other backends could be developed. There isn't a *huge* demand for this (pip and conda really are the only options in this space), but it might be useful to be able to configure different template + support package combinations as defaults.

**Implementation hints**

The affected code is all contained in `briefcase/commands/create.py`:
* The `support_package_url` property
* The `app_template_url` property
* The `install_app_dependencies()` method

If these three attributes/methods could be abstracted behind an interface, with Briefcase providing a default implementation for that interface that provides the existing behavior, an alternate Conda implementation of that interface could then be installed.

The implementation to be used would be selected early in the lifecycle of the Create command, based upon a configuration option on the app looking up a key in a list of `pkg_resources` plugins (see `setup.cfg` and `briefcase/platforms/__init__.py` for details on how plugins are used at present to define the platforms). Ideally, the plugin interface would allow any command to have overridden entry points (so - Briefcase would define a `briefcase.foundation.default.create` plugin, and a Conda plugin for briefcase would define `briefcase.foundation.conda.create`; allowing for `briefcase.foundation.default.build` and `briefcase.foundation.conda.build` et al in future, if required).

**Questions/Considerations**

A (probably incomplete) list of questions/considerations for this project:

1. How do you create a standalone, relocatable Conda environment? Are binaries installed into a Conda site-packages folder location independent? Can the `.app` folder be moved once an installation has occurred?
2. What configuration to that environment is needed to support having a `site-packages` folder in user space, *outside* the location of the packaged Conda environment.
3. Supporting Conda on non-desktop platforms (in particular iOS and Android) would be desirable, but is unlikely in the short term. How will foundation plugins notify the user that they don't support a given platform? Is there a need for a "foundation validation" step when the plugin is selected?