tools: add discover, autoport scripts - #3335

For upstream support, I've been using Claude to help cover a repetitive process for the simplest modules. These aren't the highest-value in terms of ecosystem utility (those would be modules like polars-runtime, grpcio, etc.), but in terms of general Python readiness, getting many of them building for riscv64 sooner rather than later should help justify support with more hesitant projects.

The approach I've taken follows this general pattern:

1. Identify all of the maturin-based packages we have workflows for
2. Fetch the corresponding upstream repositories
3. If they follow the most basic arch-triple-runner-manylinux pattern (see below) in the workflow's build matrix for Python, automatically update it
4. Do a quick review
5. Push to my GitHub fork
6. Run a test
7. Submit a PR to the upstream project

This PR is meant to provide tooling to help with steps 1-3, and is extended to cover cibuildwheel-based packages in addition to maturin. It should also be a good baseline to extend to cover more patterns, since right now it mainly targets projects whose build matrix takes the following shape (aarch64 as an example):

          - runner: ubuntu-24.04-arm
            target: aarch64-unknown-linux-gnu
            arch: aarch64
            manylinux: auto

and adds something like:

          - runner: ubuntu-24.04-riscv
            target: riscv64gc-unknown-linux-gnu
            arch: riscv64
            manylinux: 2_39

The two scripts themselves are fairly self-explanatory, and generated with the help of Claude. riscv64_autoport.py goes through the process of editing already-cloned repositories, while riscv64_discover.py searches for and clones any repositories which don't have some sort of RISC-V support already. Both generate JSON reports and summarize what they did. Right now, since the types of build tooling searched for and the workflow patterns to be targeted are so limited, most repositories are untouched, but we could probably add more sophisticated checking. I'd appreciate your feedback.

Note that I explicitly designed them around not automatically pushing or running any changes, either to forks of upstream repositories or PRs directly against them, since it should remain our responsibility to make sure the changes are validly written and will be suitable for maintainers to accept.