Fail before calling Py_Initialize on PyPy.

[davidhewitt]

At the moment PyPy does export a Py_Initialize symbol, which in theory we allow linking against and calling. But this is just a stub and calling it segfaults. There's an upstream issue at pypy/pypy#3836 to implement support (and I once offered, but since ran out of available time to invest in such a project at present).

Given that users can at the moment easily build PyO3 binaries with PyPy which immediately segfault, we should either:

• Panic at runtime before calling Py_Initialize on PyPy, or
• Fail to compile on PyPy e.g. by removing APIs such as prepare_freethreaded_python, and if the auto-initialize feature is enabled, maybe fail as part of the build.rs build script.

[davidhewitt]

Labelling as good first issue because I think this is a relatively localised change which will help avoid a nasty crash for unsuspecting users.

[MusicalNinjaDad]

I'd be happy to take a look at these, and have recently acquainted myself a few of the relevant areas of the code. Where I am unsure is how to test this.
From a testcase perspective I would imagine needing a mix of trybuild tests to validate the compile failures and integration tests to validate runtime panics with versions tagged #[cfg(...)] for the PyPy and non-PyPy cases.

What kind of an overall environment would be needed for this? I assume that Pyo3 uses the Python version based on the link libraries available/specified not the interactive python binary selected. I also assume there is no difference between libraries and binaries using embedded python.
Short of running the whole thing in a dedicated matrix pipeline, how would one go about installing a local setup that allows nox to run compilation and test against PyPy and cPython on demand? (I'm using a devcontainer, so it's easy enough to create a dedicated set up by just adjusting the underlying Dockerfile once I know what is needed)