Check whether check_for_negated_jmpif_condition optimization would benefit ACIR functions.

[TomAFrench]

In #5891 we started swapping the then and else branches of if-else statements in brillig functions if the if condition was being negated. Due to some issues with the flattening pass we didn't apply this optimization to ACIR functions.

The CFG allows querying the block in which the two branches will merge again:

noir/compiler/noirc_evaluator/src/ssa/opt/flatten_cfg/branch_analysis.rs

Lines 32 to 55 in 10a9f81

	pub(super) fn find_branch_ends(
	function: &Function,
	cfg: &ControlFlowGraph,
	) -> HashMap<BasicBlockId, BasicBlockId> {
	let mut block = function.entry_block();
	let mut context = Context::new(cfg);
	loop {
	let mut successors = cfg.successors(block);
	if successors.len() == 2 {
	block = context.find_join_point_of_branches(block, successors);
	} else if successors.len() == 1 {
	block = successors.next().unwrap();
	} else if successors.len() == 0 {
	// return encountered. We have nothing to join, so we're done
	break;
	} else {
	unreachable!("A block can only have 0, 1, or 2 successors");
	}
	}
	context.branch_ends
	}

Using this we can perform some inspection to determine whether we're in a situation where the two blocks merge inside of the else branch (and so swapping the condition would move it to the then branch) or whether it's save to negate the condition.