refactor: guest bindings

[Avaneesh-axiom]

This PR removes parts of the guest libraries for each extension. These libraries are to be moved into a new repo as part of the guest library re-org.

Summary of changes for each extension:

• algebra: minor changes
• ecc: the re-export of halo2curves was removed, also minor changes
• pairing: the traits, the halo2curves_shims module, along with a minimal set of constants remain in the openvm repo, while the bn254 and bls12_381 implementations were moved out
• bigint: the U256 and I256 structs were deleted. Only Rust bindings remain.
• sha256: the sha256 and set_sha256 functions were deleted, leaving behind only the Rust binding
• keccak256: the keccak256 and set_keccak256 functions were deleted, leaving behind only the Rust binding

Notes:

• the k256 and p256 modules of the ecc extension were not deleted as they are useful for testing the ecc macros and traits. For this reason, the ecc tests were also not deleted
• the algebra tests were also not deleted for the same reason
• the mod_sqrt implementation was moved from the ecc extension to the algebra extension

Benchmarks and examples are now outdated since they depend on guest libraries that no longer exist. These need to be redesigned and rewritten to use the new guest libraries. I wasn't able to easily port the benchmarks and examples because depending on the new guest libraries creates weird linker issues (I'm guessing due to double-importing openvm).

TODO:

• switch all deps to main after merge
• uncomment ecdsa test

Closes INT-3788

[jonathanpwang]

LGTM, but don't merge because we will merge the other PR into this one

[jonathanpwang]

it doesn't really matter, but what stopped you from doing a blanket implementation for all ff::Field?

[jonathanpwang]

I think this is technically not constant time because of branching

[jonathanpwang]

It is weird to keep k256.rs in ecc/guest since there is a lot of code duplication.

[jonathanpwang]

Two follow-ups, but let's merge this first:

• constant time algorithms (constant time doesn't really make sense in zkvm context I think, but let's revisit)
• redundant code for k256.rs

[github-actions]

group	app.proof_time_ms	app.cycles	app.cells_used	leaf.proof_time_ms	leaf.cycles	leaf.cells_used
verify_fibair	(-23 [-1.9%]) 1,164	334,086	17,676,626	-	-	-
fibonacci	(-37 [-1.5%]) 2,473	1,500,277	50,589,503	-	-	-
regex	(+399 [+5.4%]) 7,764	4,165,226	166,511,152	-	-	-
ecrecover	(+591 [+42.5%]) 1,980	(+339097 [+117.2%]) 628,544	(+15107986 [+104.4%]) 29,578,172	-	-	-
pairing	(-94 [-2.1%]) 4,403	(+36828 [+2.0%]) 1,857,264	(+1216224 [+1.3%]) 97,048,631	-	-	-

Commit: fa869e0

Benchmark Workflow