DON'T MERGE YET - NEED TO MEASURE CONSTRAINTS chore: Refactor

[iAmMichaelConnor]

Description

I spent a bit of time refactoring BigNum into what I hope is an easier-to-follow design.

I haven't touched any of the mathematics; just moved functions around.

Things I sought to improve:

• The BigNum and RuntimeBigNum were somewhat cyclic structs: their methods called each-others' methods. The comments in the code even mentioned this being problematic and confusing. It also meant if you tried to introduce a new method (like I tried), you could accidentally fall afoul of the cyclic-ness.
  • To solve this, I've put made all of the proper "impl" functions as "free functions" instead of methods. Both structs still exists. It's just their methods are now clean wrappers which call the free functions. This way, both structs can call those methods without any cyclic dependencies on each-other. In fact, the structs now don't know about each other at all.
• When creating a BigNum from a BigNumInstance, many of the methods of BigNum weren't available (I think because of the above cyclic problems), and the pretty operators (+,-,*,/) weren't available.
  • I think this is because really, runtime bignum is a distinct thing that deserves its own struct. So, I introduced "RuntimeBigNum", which has exactly the same methods and pretty operators as BigNum. The only difference is whether the params are known at compile-time or not.
• The above simplifications meant I could remove lots of traits and generic parameters which made the code difficult to follow. Hopefully it reads more cleanly.
• Broke big files into a few smaller files.
• Removed the "dummy struct" that needed to be declared when defining a new set of runtime bignum params.

Anyway, all the tests pass, wooh!

Lmk what you think. :)

[iAmMichaelConnor]

Looks like nightly is happy, but 0.34.0 isn't. Will investigate.

[iAmMichaelConnor]

Before:

After:

[iAmMichaelConnor]

If approved, I'll do the README