feat!: Fixing the bytesize for be, le byte serialization, adding new functionality and tests

[kashbrti]

Description

Our current to_le_bytes and from_be_bytes implementations required the bytesize to be passed as a generic.
This was offering a nonideal interface as when the bytesize was not large enough, it would cause a non-comprehensive
error.
After discussions with Zac, I decided to fix the size of the byte representations.

Also, to facilitate the blob work, I've added a to_be_bytes functionality, which is needed for BLS point compression.
This PR adds two new methods:

• to_be_bytes()
• from_le_bytes()
  These two functions have also allowed us to write fuzz tests for the byte serialization functions.
  On another note, I fixed a small bug I found, a line that was commented out for testing reasons during the switch to u128 limbs, which I just uncommented. This resolves last limb of derive_from_seed is always 1 #156 as well.

I have also included the changes in #155 in this PR to avoid merging issues.

Problem*

Resolves

Summary*

Additional Context

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[kashbrti]

I tried adding these to the macro, but I was getting complaints that the trait that implements the function is out of bounds.

[kashbrti]

@TomAFrench, there's a compiler panic that has been resolved in the nightly version.
Are we planning on pushing a new Nargo release soon?
I believe this should be related to the issue I had in #151 with associated constants.

[MirandaWood]

Not familiar with Noir benchmarks but logic etc. LGTM, thanks for adding! 🚀

[TomAFrench]

I'd like to avoid having two completely separate codepaths for serde logic just depending on the endianness. We should be able to avoid this and share logic between then (in the ultra-simple case just reverse the input/output array as appropriate).

[kashbrti]

@TomAFrench I'll just revert the arrays then. wondering how this will affect the number of constraints though. Given that these are runtime arrays, this will introduce additional RAM gates = the number of bytes the representation needs.

[TomAFrench]

I would expect this to be free in ACIR and negligible overhead in brillig. We shouldn't be using RAM gates at all in this situation.

[kashbrti]

Did a bit of experimenting. The circuit size goes from 2894 to 2905, which I believe is an acceptable increase.

[TomAFrench]

Looks like these new tests are really heavy @kashbrti.

[Savio-Sou]

@kashbrti should we update this repo's README:

noir-bignum/README.md

Line 49 in 873d901

This library is tested with all stable releases since 1.0.0-beta.0 as well as nightly.