This PR is best reviewed one commit at a time. There are two commits, the first one is the main change. The second one removes a hack to add type-stubs to blspy, which is no longer needed.

Purpose:

The purpose of moving the the BLS bindings from blspy (C++) to chia_rs (rust) is to move towards being able to perform all block validation in rust. The main benefit of this is to be able to use threads instead of a process pool for parallel block validation.

There's also a good chance the BLS cache could be a lot faster by being ported to rust.

Current Behavior:

We currently use BLST for BLS operations, wrapped with some additional features in C++ (bls-signatures) then given a python binding in blspy. This makes it very hard (near impossible) to reach the underlying BLST primitives from rust. And similarly impossible to build rust-native types with BLS elements as members.

New Behavior:

We still use BLST but the additional features have been ported to rust (in chia_rs) and given a python binding along with all other chia_rs functions and types, in the chia_rs wheel. This allows rust-native types to have native BLS members, and still be compatible with the python bindings.

For example, this enables signature validation to happen in rust (in threads rather than processes) and it allows the BLS cache to be implemented in rust.

One noteworthy discrepancy between blspy and chia_rs is that the PrivateKey data is not allocated in "secure memory" yet, in chia_rs. i.e. mlocked and zeroed out.

Testing Notes:

How do we know that the BLS types in chia_rs behave the same as blspy?
There's a fuzzer that calls into blspy to compare the results from chia-bls here:
https://github.com/Chia-Network/chia_rs/blob/main/chia-bls/fuzz/fuzz_targets/blspy-fidelity.rs

There's a fidelity test exercising the python bindings of both chia_rs and blspy here:
https://github.com/Chia-Network/chia_rs/blob/main/tests/test_blspy_fidelity.py