--warn-as-error prevents next stage from running if it finds any warning

[timotheeguerin]

The compiler will not move to the next stage if it finds an error. However when we use --warn-as-error this update the diagnostic to be an error immediately at report type not when displaying it at the end.

This is makes the --warn-as-error have a worse experience as it can't keep going if some minor elements that shouldn't prevent the next stage from running were found.

[tjprescott]

If you run tsp compile . --warn-as-error, which we do in CI, and your spec has compiler warnings (think onValidate) as well as rule violations, the conpiler will stop, only emit the compiler warnings, fail, and exit without actually running the rules. This is manifesting on CI where the compile step exits due to a deprecation warning and thus doesn't run the actual linter rules.

--warn-as-error should collect all diagnostics, from the program AND rules, and only then apply --warn-as-error

[tjprescott]

Also, in discussion with @timotheeguerin, --warn-as-error makes warning violations appear as errors in the output. It seems to me that it should display as the correct thing (warning or error) but simply exit with code 1 after all program and linter diagnostics have been collected if there are any warnings or errors.

[timotheeguerin]

There is a few options:

1. Only patch the diagnostic at the end of the compile. This has the cons that people might get an inconsitent behavior when looking at the diagnostics
2. Make sure we don't count a warning as an error for deciding to go to the next stage with an extra flag/state
3. Stop converting warnings to errors and instead just return non-zero exit code if --warn-as-error is specified. This has the advantage of still exposing the different status to the user and not confuse them with things that could be suppressed.

[tjprescott]

I'd vote for 3.

[markcowl]

est: 2 for implementing the second option