fix: add new BrilligFunctionUnsatisfiedConstrain resolution error variant

[anaPerezGhiglia]

Description

When an assertion fails on Brillig mode, the debugger fails to indicate the user where the program failed

while when running on ACIR mode it provides enough information 👇

Problem

Resolves

Summary

Context

assert constraints are translated as "jump to trap" if the condition is not met when running in Brillig mode

Changes

• Add a new variant OpcodeResolutionError::BrilligFunctionUnsatisfiedConstrain to represent failed constraints on Brillig
• Return this new error when brillig code fails due to a Trap failure
• Return the ownership of the solver to brillig context when the debugger fails due to this new resolution error so that the the last opcode is known for showing the error
• Changed the variant checking on ACVM.map_brillig_error from OpcodeResolutionError::BrilligFunctionFailed to OpcodeResolutionError::BrilligFunctionUnsatisfiedConstrain since assertion errors will now fail with the latter
• Add new branch on related match expressions to treat the new variant the same way as BrilligFunctionFailed for all other cases

Observations

• should we return the solver ownership to the brillig context in all Err scenarios? At first sight it seems that this would be the right thing to do, but I decided to handle only this known scenario in case I'm missing something.

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]

Thank you for your contribution to the Noir language.

Please do not force push to this branch after the Noir team have started review of this PR. Doing so will only delay us merging your PR as we will need to start the review process from scratch.

Thanks for your understanding.

[TomAFrench]

I would say that replacing the brillig solver in all cases is probably the way to go in this scenario. I think it was probably left off due to an expectation that execution has finished so we can discard the VM.

[TomAFrench]

I expect that this doesn't require the new error variant now, correct?

[anaPerezGhiglia]

@TomAFrench I guess the need of the new variant is debatable. I left the new variant since with it

• we have a better explanation for the user about what happened. With the new variant the executor shows "Cannot satisfy constraint", while without it shows "Failed to solve brillig function"
• it feels better to check against a specific constrain error in map_brillig_error function