Include licenses of all Python packages

Nobody has claimed this yet.

The inclusion of all licenses for the Python runtime components is very nice.

However, the licenses of the Python packages built into the binary is just as important - possibly even more so because the licenses were often chosen assuming the package would not be *linked*/*embedded* into a larger work, and there is less appreciation of those aspects of license chooses in the Python world because the source is normally the executable/redistributable.

Where PKG-INFO or EGG-INFO exists, which should be most of the time, there is a [License free text field](https://www.python.org/dev/peps/pep-0314/#license) which looks like `License: MIT`. Sometimes it contains SPDX compatible names, other times it is ambiguous like `License: BSD`. The Trove classifiers are also ambiguous, e.g. `License :: OSI Approved :: BSD License`. And I have seen quite a lot of cases where a package has discrepancies between the trove classifiers, `License:` and `LICENSE.txt`.

https://pypi.org/project/pip-licenses/ looks like it is quite useful to sort out that mess.

The wheels usually now contain a LICENSE file. It can be explicit with the following in setup.cfg , however modern setuptools now aggressively finds and includes one if it exists when building a wheel (and possibly also when building an sdist).
```ini
[metadata]
license_file = LICENSE.txt
```

IMO a good solution would be to try to get the license text file out of the wheel or sdist, and error/warn bitterly if one was not locatable, rather than playing games with the PKG-INFO/EGG-INFO text field, which is still insufficient if the license any that requires redist of the license text including custom notices, such as Apache-2.0.

IMO it is easy to get Python projects to add a LICENSE file, even when the project is otherwise moribund. Getting a new package release with the LICENSE might be more difficult, but often in that case a `git+https://` or `master.zip` requirement solves the problem.(I assume those can be used with PyOzidizer)

The filtering on licenses should also apply to Python packages, and probably more errors/bitter warnings needed there. It would also be wise to have a default filter in place for GPL, so PyOzidizer errors unless users explicitly allow GPL packages in the project toml file.

Start by reviewing how PyOxidizer handles Python packages and the project TOML configuration, then inspect the package metadata in PKG-INFO or EGG-INFO and LICENSE files in wheels or sdists. Compare the proposed approach with pip-licenses and determine how license collection, missing-license warnings, and GPL filtering should behave. Done means the behavior is defined for conflicting metadata and license text sources.

Written by the indexing model from the issue text.