Python as an optional dep

PyO3, useful as it is, can take up time during compilation in both the copper repo and for users. It'd be best to define it as a --feature for those who want to opt in to python bindings instead of requiring it.

In my project, im using cross to handle cross compilation and I needed to do some minor configuration to get it working

[build]
default-target = "aarch64-unknown-linux-gnu"
# it's possible i can compose different Cross tomls per crate, but I'll just make a mega one here
# - copper requires python3 for py03 support
pre-build = [
    "dpkg --add-architecture $CROSS_DEB_ARCH",
    "apt-get update && apt-get --assume-yes install python3:$CROSS_DEB_ARCH",
]
[build.env]
# No idea if this is even the version installed to the container, i just need one defined
passthrough = ["PYO3_CROSS_PYTHON_VERSION=3.12"]

Right now, python is defaulted as disabled. We can flip that if we want it on by default.

I've also kept it as disabled on macOS. We could leave it platform-agnostic and just not enable it on CI for macOS. I'd prefer that approach but went with the current state of things.

Looking at the docs https://pyo3.rs/v0.4.1/overview#using-rust-from-python, we need to do some shared lib renaming, and ditto for windows. Apparently that can be handled during python packaging but I don't think it's really worth the effort at the moment.

Python module naming

As I was poking around into the python setup, i noticed this https://github.com/copper-project/copper-rs/blob/master/core/cu29_export/build.rs#L6

f we're alright with python interfaces importing the module as

import libcu29_export

we'd be able to use python interfaces without violating the OUT_DIR sandbox https://doc.rust-lang.org/cargo/reference/build-scripts.html#outputs-of-the-build-script. We could also rename the pymodule to libcu29_types , libcu29, libcu29_reader but i think that'd just be more confusing.

Ideally, we'd be able to just symlink the output or handle renaming in cargo, but that isn't supported rust-lang/cargo#1970

I tested this out locally with examples/cu_standalone_structlog/readlog.py and got it to the point where it tried to read a log but I didn't have one so it raised an exception. I figured that's better than hitting a pybind exception.