chore: remove temporary allocations from num_bits

[TomAFrench]

Description

Problem*

Closes #4759

Summary*

I found this due to #6550.

We make heavy use of the num_bits method during compilation but this is currently doing a lot of unnecessary allocations in order to perform a full bit decomposition of the field element. We can rework this to work on the byte decomposition which removes 96% of all the temporary allocations from compilation.

Additional Context

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

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

[asterite]

Incredible! On Friday I was looking at small and quick optimization opportunities and found a couple of them, one of them was this one (not with this algorithm, but I noticed num_bits was allocating too much).

Another thing I found is that FieldElement::hash does state.write(&self.to_be_bytes()); but I was wondering if we could directly call self.0.hash(state), which seems to compile but I don't know why that's not done (though I don't know if it's more efficient).

Another one I found was this double hashmap lookup:

noir/acvm-repo/acvm/src/compiler/transformers/csat.rs

Lines 274 to 275 in 7311d8c

	if intermediate_variables.contains_key(&normalized_expr) {
	let (l, iv) = intermediate_variables[&normalized_expr];

but I didn't send any PR because I wasn't sure if any of those improved the performance, really.

[asterite]

Looks good! I left a comment for something that might require an additional test.

[TomAFrench]

Another thing I found is that FieldElement::hash does state.write(&self.to_be_bytes()); but I was wondering if we could directly call self.0.hash(state), which seems to compile but I don't know why that's not done (though I don't know if it's more efficient).

I can't see any meaningful benefit for this and it'll remove an allocation so let's do it.

[TomAFrench]

Another one I found was this double hashmap lookup:

We end up hitting our peak memory usage during SSA rather than in the post-compilation transformations so I think we can ignore this for now.