Error and ICE reporting tweaks

[cameel]

This is an assortment of small improvements in error reporting:

• AsmAnalyzer::analyzeStrictAssertCorrect() now includes pretty printed source and the error list in the assertion message. This will make it easier to triage cases like #15889 and is the most important change here.
• SourceReferenceFormatter was not printing source locations for files with an empty name. This is a perfectly valid case in Standard JSON. We also use such names for internally generated Yul and in test suites.
• Failed Yul assertions and Yul StackTooDeep errors (not to be confused with completely separate langutil StackTooDeep errors; WTF) are now handled properly in Solidity mode: the former as ICE, the latter as a normal error.
  • ICEs in Standard JSON now properly include all the same diagnostic info we provide on the CLI. Until now this was being done only for uncaught exceptions, not failed assertions.
  • StackTooDeep errors on the CLI now show a proper error with location rather than the hairy diagnostic info meant for ICEs. This fixes Stack too deep exception is not being caught #15740.
  • Note that this is still a mess in many ways. E.g. we have separate exception handlers for Yul and I did not touch those.
• The assertion that's triggered by invalid IR coming out the generator now shows error codes (and source locations due to the other fix mentioned above).

[cameel]

This one does not actually fix anything but I decided to change it to be less of a head-scratcher.

We usually output to the ANSI stream using <<, but here it's just created and we ignore it. I initially thought it was a bug and that coloring must be broken because of it, but it works. Apparently the control codes are issued at construction and destruction time.

[cameel]

We should simplify this one day and make all assert macros throw InternalCompilerError. Having different types and even documenting them in Error types just unnecessarily exposes implementation details to the user. We should only have compilation errors there. It's especially confusing when things like SMTLogicError are actually failed assertions.

[cameel]

Note that this affects also the errors reported by the assert in CompilerStack::loadGeneratedIR().

Instead of this:

Invalid IR generated:
Error (6913): Call or assignment expected.

Error (8143): Expected keyword "data" or "object" or "}".

we'll now see this:

Invalid IR generated:
Error (6913): Call or assignment expected.
 --> :7:9:
  |
7 |         mstore(64, memoryguard(128))
  |         ^^^^^^

Error (8143): Expected keyword "data" or "object" or "}".
 --> :7:9:
  |
7 |         mstore(64, memoryguard(128))
  |         ^^^^^^

Another thing it affects are Yul test case variants that use the empty name for the source they parse and don't allow errors in expectations. The formatted errors are instead included in the exception they throw.

[cameel]

This is what it looked like before the change:

Uncaught exception:
/solidity/libyul/backends/evm/EVMObjectCompiler.cpp(110): Throw in function void solidity::yul::EVMObjectCompiler::run(const solidity::yul::Object&, bool)
Dynamic exception type:
std::exception::what: Cannot swap Variable value23 with Slot 0x20: too deep in the stack by 9 slots in [ RET value23 value22 value21 value20 value19 value18 value17 value16 value15 value14 value13 value12 value11 value10 value9 value8 value7 value6 value5 value4 value3 value2 value1 value0 pos 0x20 ]
memoryguard was present.
[solidity::util::tag_comment*] = Cannot swap Variable value23 with Slot 0x20: too deep in the stack by 9 slots in [ RET value23 value22 value21 value20 value19 value18 value17 value16 value15 value14 value13 value12 value11 value10 value9 value8 value7 value6 value5 value4 value3 value2 value1 value0 pos 0x20 ]
memoryguard was present.
[solidity::langutil::tag_sourceLocation*] = stack_too_deep_from_code_transform/input.sol[0,206]