Add a cargo feature to panic! early on compile errors for easier sway-core debugging?

[mitchmindtree]

During compilation, sway-core will avoid returning early on most compilation errors in order to give as much feedback to the user as is possible. This is great for the user, but can make things a bit tricky when trying to determine the source of an unintentional compile error during sway-core dev.

One thing I found myself doing quite frequently while solving bugs in #1213 was printing the checkee's span during TypedAstNode::type_check and then printing the error count at the end to work out exactly which node variant causes the error accumulation to begin.

I wonder if it might be useful to have some cargo feature, i.e. panic-on-err or something that we can use solely during debugging that causes the CompileResult err constructor to immediately panic! so that we can get a quick stack-trace directly to the site that raises the error? This might be a nice alternative to manually hunting down what CompileError was raised and where it was raised?

[sezna]

That's nice, and it wouldnt be hard to implement: we can just hook into ok(), check!() and err() via conditional compilation. That'd immediately cover 99% of cases.