Add `--strict` option that treats warnings as errors

[susan-davis]

Many warnings conceal ticking time bombs in the code that can manifest into full blown bugs. Having the option to fail the build on any warning, to ensure that warnings are dealt with, would be helpful.

[dstelzer]

That seems reasonable as an opt-in thing, but we should check what un-silenceable warnings the compiler currently produces. For example:

• Using --override-serial
• If no file defines (library version)
• If the file containing (library version) is not the last on the command line

All of these are warnings, because if you don't have a specific reason for doing them, you shouldn't. But if they're done deliberately (e.g. writing a standalone Dialog program that doesn't use the library), there's currently no way to turn the warnings off. This shouldn't cause a build to fail.

[dstelzer]

A quick grep turns up a few more:

• If display: none; is used on a span instead of a div (legal, but the spacing behavior is unintuitive)
• Not supplying metadata like title and author (e.g. for a unit test that's not going to be released as a standalone game)
• If the compiler can't prove that all arguments in a (now) expression will be bound

[susan-davis]

Warnings for potential typos:

• never using a variable that you've named
• never calling a predicate that you've written, and it also isn't covered by an interface

[dstelzer]

True, but those ones I'm not worried about for this—you can fix those warnings by adding an interface or removing the variable name (make it just $).

[dstelzer]

I suppose we could add a new logging level, WARN_NONFATAL.

Or we could use the NOTE logging level, which is always printed regardless of verbosity, just like WARN is. But several of these imo should be warnings, because you should only do these things if you understand the repercussions.