Add 'severityOverride' option

[elsassph]

bsconfig.json now accepts a severityOverride map allowing to adjust a diagnostic severity.

Fixes #724 - see issue for details

[elliot-nelson]

Really interesting. Like tsc, bsc doesn't have an "eslint-esque" rules engine where there's a very clear way to turn on and off errors and give them different severity levels.

Instead, TS "rules" are governed by human-readable options that are kind of disjointed from the error message you get... i.e., when your build pops out TS7006: foobar has implicit type 'any', that doesn't inform you that you could disable that by setting compilerOptions.noImplicitAny: false.

So, I like your approach, although I see two issues:

• If you change errors to non-errors, might you accidentally cause your build to succeed (exit code 0) even though your formatted output might be incorrect / non-runnable? Or are there still errors that are so bad the whole compiler just chokes up. (Maybe there's a "fatal" level that never reaches the diagnostic stage.)
• The name severityOverrides seems very specific and almost a dirty hack, whereas I think this use case probably has a number of legit purposes. Would a structure more like compilerOptions: { diagnostics: { 1004: "error" } } seem less dirty?

[elsassph]

Yes @elliot-nelson, the whole point of this setting is to be a workaround - it should feel nasty!

Unlike eslint, plugins contributing to diagnostics can be heterogeneous so yes, this property is meant to be seen as a "workaround", which is useful when transitioning a project to bsc/bslint (as our colleagues are doing) where a lot of errors can be non-fatal in the current state of the codebase but need time to clean up.

[TwitchBronBron]

Let's call this diagnosticSeverityOverrides instead? Keeps it more in line with diagnosticFilters