Provide a way to uninstall "features" of the standard library

### What is the problem or limitation you are having?

The Python support package is, by design, "batteries included". This is great for desktop apps, because it means the default install has a lot of features; but it poses a problem for distributed apps. Briefcase is faced with the choice of:
1. Include all features, even though most users won't need them, or
2. Strip selected features, and manage reports of users who *do* need those features.

Consider tkinter as an example. If you're distributing a Toga or Qt or PyGame app, you won't need Tkinter. It's a very large library, with a lot of binary components. However, if you're building a tkinter app, you obviously need the library and it's binary components. This means that Briefcase is faced with the choice of including tkinter, and having the distributed binaries be much larger than required; or stripping tkinter, and getting reports like #318.

### Describe the solution you'd like

The Briefcase support packages should provide a way to declare "features" that can be removed from bundled app.

This could be expressed as either an additive or subtractive list of features - i.e., it could be expressed in terms of "include everything *except* these 3 parts of the standard library", or "start with a minimal viable interpreter, and add these 3 additional parts.

This feature overlaps with `cleanup_paths`. A "feature" is a pre-defined collection of cleanup patterns that can be defined in a support package's metadata.

As example syntax:
```
python_features = ["bz2", "unittest"]
```
would install a minimal interpreter, but include the bz2 and unittest libraries.

```
remove_python_features = ["tkinter"]
```
would install a full interpreter, but remove tkinter.

### Describe alternatives you've considered

* Do nothing. `cleanup_paths` exists, and can be used to remove unneeded components
* Work upstream with Python core on a "minimum viable Python", so that components like tkinter become installable with pip. Having a working "feature set" feature in Briefcase might be a useful proof of concept for any upstream discussions

### Additional context

One potential complication: How can/should a package on PyPI declare which parts of the standard library it requires? If you remove the `bz2` feature, but you specify something that has `bz2` as a requirement, is there any way to flag this as a problem other than a `ImportError` at runtime?

The list of features doesn't have to be limited to parts of the standard library. The discussion around beeware/briefcase-macOS-app-template#7 suggests that the Python binary itself might be a "feature" that could be included/excluded in a distributed binary.

Begin by tracing the existing cleanup_paths mechanism and support-package metadata, since the issue identifies them as the closest related entry points. Define how additive and subtractive feature declarations should work, including conflicts with package requirements; done means a support package can declare standard-library features and bundled apps consistently include or remove them.

Written by the indexing model from the issue text.