fix: add new BrilligFunctionUnsatisfiedConstrain resolution error variant

[anaPerezGhiglia]

this is an alternate solution to #5
it has more effects outside the scope of the debugger, but it feels more accurate

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 👇

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 the other cases

Observations

• TODO: should we return the solver ownership to the brillig context in all Err scenarios>?

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.