Implemented add, mult, inv, sub, div, pow and neg for binary fields and wrote tests for each function

[martinsander00]

Only file to review is bf.rs inside /algebra/ff/src/fields

Description:
Implemented add, mult, inv, sub, div, pow and neg for binary fields and wrote tests for each function.

Description

closes: #XXXX

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (master)
• Linked to GitHub issue with discussion and accepted design OR have an explanation in the PR that describes this work.
• Wrote unit tests
• Updated relevant documentation in the code
• Added a relevant changelog entry to the Pending section in CHANGELOG.md
• Re-reviewed Files changed in the GitHub PR explorer

[tcoratger]

Here why not implementing directly the Add trait like this is done here for example? I think this is also applicable to sub, mul, neg... so that we can use directly +, -, * operations

algebra/ec/src/pairing.rs

Lines 192 to 200 in 9ce33e6

	impl<'a, P: Pairing> Add<&'a Self> for PairingOutput<P> {
	type Output = Self;
	#[inline]
	fn add(mut self, other: &'a Self) -> Self {
	self += other;
	self
	}
	}

[martinsander00]

Will do this! Thanks for the suggestion

[tcoratger]

I think we can integrate this method directly inside the BinaryFieldElement impl no? using:

fn binmul(&self, rhs: Self, length: Option<usize>) -> Self {

[martinsander00]

SO we could, but why would someone use binmul instead of mul? I think mul is more intuitive right?

[tcoratger]

can we add some randomized tests here as this is done here for example? https://github.com/arkworks-rs/algebra/blob/master/ff/src/biginteger/tests.rs

[martinsander00]

done! Thanks for the suggestion

[tcoratger]

Here I'm not sure this way of doing things is the more efficient approach because no matter the size of the field concerned, you store in your value as BigUint a vector of BigDigit (u64 or 32 I think) but for field extensions before 32, we don't need as much space.

So I wonder if it is not more optimized to do something custom made like this:

https://gitlab.com/IrreducibleOSS/binius/-/blob/main/crates/field/src/binary_field.rs?ref_type=heads#L770-L777

so that we can have a very efficient implementation for small extensions.

[martinsander00]

This makes a lot of sense, but it would mean implementing a separate Binary Field implementation for each field size. Should I submit these changes as part of my next PR, or should I first push the other changes we discussed (operators and moving binmul) and then implement the different field sizes in subsequent PRs?