Pyoxidizer

See https://gregoryszorc.com/blog/2020/04/09/pyoxidizer-0.7/ for the blog post accompanying this release.

The over-arching theme of this release was focusing on improving PyOxidizer's compatibility with various packages. It has done so by:

* Supporting loading extension modules from standalone files.
* Reusing pre-compiled extension modules in Python binary wheels
* Better support for loading Python resources from the filesystem
* Improved handling of Python package resource files
* Initial support for package distribution metadata (`.dist-info` and `.egg-info` directories)
* And lots more. See the full changelog at https://pyoxidizer.readthedocs.io/en/stable/history.html

This is a relatively minor release. The full changelog is at https://pyoxidizer.readthedocs.io/en/stable/history.html#version-0-6-0.

Meaningful changes in this release are:

* The `pyembed` crate is now published on crates.io and can be used like any other crate.
* We now use the upstream `cpython` crate instead of a fork of it.
* Embedded Python interpreters can now be configured to run a file (in addition to executing code, a module, etc).

This release also lays the groundwork for different Python distribution *flavors*. The goal of this work is to support other Python distribution types instead of the highly opinionated statically linked distributions we currently require. For example, we want to eventually support using existing Python distributions discovered from the filesystem as well as distributions that use more traditional dynamic linking. These features will materialize in a future release.

This release of PyOxidizer is significant rewrite of the previous version.
The impetus for the rewrite is to transition from TOML to Starlark
configuration files. The new configuration file format should allow
vastly greater flexibility for building applications and will unlock a
world of new possibilities.

The transition to Starlark configuration files represented a shift from
static configuration to something more dynamic. This required refactoring
a ton of code.

As part of refactoring code, we took the opportunity to shore up lots
of the code base. PyOxidizer was the project author's first real Rust
project and a lot of bad practices (such as use of `.unwrap()`/panics)
were prevalent. The code mostly now has proper error handling. Another
new addition to the code is unit tests. While coverage still isn't
great, we now have tests performing meaningful packaging activities.
So regressions should hopefully be less common going forward.

Because of the scale of the rewritten code in this release, it is expected
that there are tons of bugs of regressions. This will likely be a transitional
release with a more robust release to follow.

The documentation for this release is at https://pyoxidizer.readthedocs.io/en/pyoxy-0.2.0/pyoxy.html.

* Official release artifacts now contain Python 3.8 and 3.10 variants.
Previously, only Python 3.9 was provided.
* The Sphinx documentation now contains extensive documentation for the
Python interpreter configuration structs and enums. The content is derived
from the canonical Rust source code. This should make it easier to
understand the fields in YAML configurations without having to consult
Rust crate docs.
* Release artifacts are now ``.tar.gz`` files and contain a ``COPYING``
file with licensing annotations.
* The release mechanism for PyOxy is now streamlined, hopefully enabling
faster releases going forward.