chore: Add Instruction::map_values_mut

[jfecher]

Description

Problem*

Working towards #6751

Summary*

I noticed in a few places we use Instruction::map_values we clone the instruction beforehand to get around borrowing restrictions. This means we should mutate in place though instead of using map_values to produce another Instruction value, so I've added map_values_mut for Instruction and DataBus and searched through to find each case we could use these as well as the existing TerminatorInstruction::mutate_values which I've renamed.

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.

[github-actions]

Compilation Sample

Program	Compilation Time	%
sha256_regression	0m1.500s	5%
regression_4709	0m1.443s	-4%
ram_blowup_regression	0m16.177s	-3%
private-kernel-tail	0m1.335s	-3%
private-kernel-reset	0m10.752s	4%
private-kernel-inner	0m2.906s	17%
parity-root	0m0.854s	-15%
noir-contracts	2m41.256s	-6%

[github-actions]

Peak Memory Sample

Program	Peak Memory
keccak256	81.37M
workspace	121.99M
regression_4709	333.17M
ram_blowup_regression	2.53G
private-kernel-tail	232.47M
private-kernel-reset	1.24G
private-kernel-inner	338.30M
parity-root	199.36M

[TomAFrench]

I'm not seeing a big benefit to the peak memory usage here although the heaptrack profiling was done on the rollup-base-private circuit which our CI doesn't currently track. I'll profile this again tomorrow to see if we should go ahead and merge.

[jfecher]

@TomAFrench I'd think this change would generally benefit runtime speed more than memory use since the extra clones we did before would just get freed afterward anyway. I'm not sure why the time for private-kernel-inner seems to have noticeably increased though.