Refactor/ipa multipoint interfaces

[thomas-quadratic]

This PR initialise a refactor of the JNI/FFI_interface to standardize the interfaces between Java and Rust.

Notably, we want to leverage only crypto-primitives related to vector commitments from rust-verkle.
Any verkle logic is for besu-verkle-tries.
Moreover, methods are composable since they follow a uniform format.

Here are the new features:

• Inputs and outputs between java and rust are rlp-encoded with all values being little-endian bytes.
• types module includes 3 types: CommitmentBytes, CommitmentBytesCompressed, ScalarBytes. These are the only primitives that are used by the ffi-interface.
• convert modules implements conversions to and from rust-verkle types.
• encoding/decoding modules implements rlp Decodable and Encodable for our types.
• traits module includes Committable and Updatable for vector commitments functionalities.

[kevaundray]

This PR takes code from ffi_interface meaning that this repo explicitly needs to know about ark-ed-on-bls12-381-bandersnatch and banderwagon -- I don't think this is the right abstraction to take, as it leaks details about the cryptography downstream. ffi_interface never exposes details about the underlying curve, banderwagon because this is just not important for downstream crates for example.

If there are changes that are needed for the cryptography interface, then ideally this is done in ffi_interface and not in besu_native, so besu_native only ever imports ffi_interface.

RE RLP -- I'll have to defer to @matkt or someone who knows more -- from looking at the rest of the packages, this doesn't seem like the right place to add RLP related code, perhaps besu-verkle-trie is where it should be?

[matkt]

If the Besu native APIs expect a specific RLP format, I think the Java objects should be in the Besu native repo (java object), and these objects should have a serialize() method that will construct the RLP. This is so that there is no need to look at the native code to understand how the RLP should be constructed.

[matkt]

do we need to keep that ?

[matkt]

This PR takes code from ffi_interface meaning that this repo explicitly needs to know about ark-ed-on-bls12-381-bandersnatch and banderwagon -- I don't think this is the right abstraction to take, as it leaks details about the cryptography downstream. ffi_interface never exposes details about the underlying curve, banderwagon because this is just not important for downstream crates for example.

If there are changes that are needed for the cryptography interface, then ideally this is done in ffi_interface and not in besu_native, so besu_native only ever imports ffi_interface.

RE RLP -- I'll have to defer to @matkt or someone who knows more -- from looking at the rest of the packages, this doesn't seem like the right place to add RLP related code, perhaps besu-verkle-trie is where it should be?

Indeed, having RLP here is a bit strange. However, I think it's necessary to consider the performance aspect to see if it allows for faster processing rather than having to do multiple JNI<>Java round-trips. Once we have the benchmarks, we can determine if it's worth exploring the RLP further or if we need to approach it differently.

[thomas-quadratic]

Deprecated.