Configurable illegal constructs

Motivation

There are some constructs that are legal SQL but are almost certainly mistakes if found in a static, handwritten query.

The primary examples that come to mind are:

NULL comparison is always false.

select * from Foo where Bar = null
-- `expr = null` is always false, should probably be `Bar IS null`

UPDATE/DELETE without WHERE clause is usually a mistake

update User set Email = @newEmail
-- uhhh... you probably forgot to put `where Id = @userId`

Idea

RZSQL should have some "linters" that implement a visitor for SQL statements and expressions (like ASTMapping.fs but without any output). There should be a separate linter class for each type of bogus construct we can think of.

In rzsql.json there could be an option like so, to determine which linters will run on the SQL statements in the project.

    "constructs": {
         "allowed": ["MissingWhereClause"],
         "banned": ["NullComparison", "UnsafeInjectRawSQL"]
    }  

This would let you override the linters enabled/disabled. Having both a whitelist and blacklist would let us pick a reasonable set of default linters that wouldn't be overly strict or overly lenient.

Linters would be named after the construct they throw an error upon recognizing. This way the constructs configuration setting reads like a list of what kinds of SQL are allowed and banned in your project. The goal here is to avoid the double-negative confusion that would result from something like the below, where we are effectively saying "we DON'T want the linter that checks for NOT having a where clause, because we DO want those statements in our SQL code".

    "linters": {
         "blacklist": ["NoMissingWhereClause"],
         "whitelist": ["NullComparisonAlwaysFalse", "NoUnsafeInjectRawSQL"]
    }

Start by reading ASTMapping.fs to understand the existing SQL visitor patterns, then inspect the rzsql.json configuration documentation. Define the scope of the linter configuration around the listed constructs, including NULL comparisons and missing WHERE clauses. Done means the project can select allowed and banned constructs and report the configured violations.