Validate more on assertion builds, and abort on errors

[maleadt]

This PR add a jl_is_assertsbuild function (cfr. jl_is_debugbuild) for checking if this is an assertions build.
It's used in two places:

1. to enable IR validation, which currently (rather weirdly) depends on -g2
2. to make internal compiler errors fatal

Both these changes are intended to help PkgEval in detecting more issues (invalid Julia IR) and make for more robust detection (a fatal signal instead of having to grep logs for Internal error, which leads to false positives).

RFC because people actually working on the compiler might have opinions about the process not aborting if invalid IR is encountered.

cc @gbaraldi

[gbaraldi]

There is also

julia/base/compiler/optimize.jl

Lines 1059 to 1063 in 31a9f13

	if JLOptions().debug_level == 2
	for i = (oldidx + 1):last(sv.cfg.blocks[block].stmts)
	@assert i in sv.unreachable
	end
	end

[maleadt]

@nanosoldier runtests()

[nanosoldier]

The package evaluation job you requested has completed - possible new issues were detected.
The full report is available.

[maleadt]

Looking at that report, running with additional verification/validation makes PkgEval on an assertions build 2.3% slower. That seems worth it, given the 12 IR corruptions uncovered here. I'll work on (filing issues to) fix those, and hopefully we can merge this afterwards.

[gbaraldi]

This found a lot more than I had expected, so I guess it's worthwhile. It's interesting that LLVM doesn't complain about these, because a lot of them seem to be malformed Phi nodes

[maleadt]

Keno fixed all of the issues I filed, so let's test again:

@nanosoldier runtests()

[nanosoldier]

The package evaluation job you requested has completed - possible new issues were detected.
The full report is available.

[maleadt]

CI failures unrelated (this only affects asserts builds), and PkgEval shows that this doesn't introduce additional failures.