Make circuit crate generic over BitzIntRing

[frozenspider]

Goes toward #136

• Introduce BitzSemiring and BitzRing traits (with blanket implementations) and abstract circuit crate over it as much as was viable.
  • The only implementations we use today are still BigUint and BigInt respectively, but they aren't hardcoded anymore (except for p256, there we merely alias them)
• Also introduce Bits and IntoWords traits to help this abstraction.
• Slightly tweak code toward more idiomatic approach - From trait, LazyLock, thiserror crate.

Nothing in this PR changes observable behaviour.

This is made into a separate self-contained PR in order to make the overall rework more granular.

[zkfriendly]

LGTM, thanks. Left a minor comment

[zkfriendly]

Interesting workaround of crypto-primitives interface. I explored this a bit, and I was wondering if we can relax the CheckedNeg bound upstream? Also since SemiRing already requires checked_sub one could implement checked_neg like:

fn checked_neg(&self, x: &R) -> Option<R> {
    R::zero().checked_sub(x)
}

[frozenspider]

crypto-primitives strives to be generic, and having checked sub/rem sounds like a reasonable thing for a ring consumer to use. Also, we can't use this workaround as a blanket for semirings since it would interfere with upstream types that provide actual CheckedNeg.
What we can do upstream though is to make a BigInt wrapper similarly to crypto_bigint::Int one, but that doesn't seem necessary in this case.

Btw here's the PR I opened to BigInt to implement missing traits: rust-num/num-bigint#357

[zkfriendly]

great