Refactoring of the debugger

[iFrostizz]

Motivation

Initial issue: we cannot use breakpoints when launching the debugger through forge debug
This uncovered the fact that the debugger code is a bit confused.
For instance, when launching the debugger from forge test, we had to instantiate a ScriptArgs struct, which is the struct we were instantiating with forge script --debug.

Solution

Create a new struct DebuggerArgs that any part of the code should comply with in order to launch the debugger.
Side effect:

• fixes forge(debug) goto breakpoint does not work when the debugger is invoked with forge debug #5510
• Adding breakpoints for fuzz (& invariant?) testing
• Reduces the debugger launching time because we don't have to run the test again (we do for fuzzing tho)

[mattsse]

heads up, we moved all crates to a crates folder,

sorry about the inconvenience

[iFrostizz]

Seems good, need to add back support for fuzz testing (optimized debugger for fuzzing btw!!)
We may open a new PR of cleanups of the Tui. For instance instead of passing the source mappings and stuffs to the drawing functions, put them all in the Tui implementation.

[iFrostizz]

Could also bundle breakpoints and debug_arena together as they are passed around a lot together

[iFrostizz]

@Evalir @mattsse any idea about This issue about the fuzzer please ?
After this smol refactor for being able to single_fuzz, the fuzzer is super slow if there is a counterexample (you can try with vm.assume(false). Probably not returning on the first counter-example or something, but it might be specific to proptest and I'm not very familiar with this lib.

[iFrostizz]

Should be gtg! Source mapping on cast run are working also but don't seem to be very correct
edit: probably because of optimization turned on

[Evalir]

@iFrostizz amazing! was just wondering—this ended up being quite big haha, and touches a few sensitive things—was wondering if it's possible to split the PR into several smaller ones? it's ok if they all merge to an specific branch, it's just a lot to review

[iFrostizz]

Yes, good idea @Evalir Sorry for that it was not planned at all but appeared to be necessary. I'll break that into multiple PRs, how much do you wanna review ideally ? +-500 lines ?

[Evalir]

yup around 500 lines is good (although if some parts are intertwined no biggy if one ends up being a tad bigger than that)! no worries—we're all guilty of big prs, this is great work!

[Evalir]

wondering @iFrostizz — is this closeable as this was split?

[iFrostizz]

Yep @Evalir , let's close!