Fix __init__ exports when using multiple UniFFI bindings

[Nickersoft]

This PR is a continuation of the work started in #1910 and #2208 that updates the generated __init__.py to export from all Python files and not just the one it assumes has been created for the local project.

Closes #2294.

There is one remaining concern I have, and that is around dylib files. I believe each crate that uses a UniFFI may try to reference its own dylib file, but only a single dylib will exist in Maturin's build directory. So I'm still not sure the expected strategy here or how that should be managed for multi-crate projects.

[Nickersoft]

Strange that these tests are failing – they all pass locally for me when running cargo test. Does anyone have an idea as to why?

[messense]

@Nickersoft You need to have uniffi-bindgen in PATH, otherwise it will skip running related tests.

[Nickersoft]

Thanks @messense! I got a lot more tests to pass now. There are still some Windows failures though, as it can't find a Python interpreter for some reason. Any idea why? Didn't think I changed anything that would affect it.

[messense]

Don't worry about it, it's an existing issue.

[messense]

Thanks!

[messense]

There is one remaining concern I have, and that is around dylib files. I believe each crate that uses a UniFFI may try to reference its own dylib file, but only a single dylib will exist in Maturin's build directory. So I'm still not sure the expected strategy here or how that should be managed for multi-crate projects.

Can you open an issue with a repro to track this?