Let packages define their own lints

[jtrakk]

It would be nice if packages could define their own lints to provide usage tips and warnings for their package.

[David Anthoff]

In general this would be very useful, in particular when it comes to macros that introduce new valid names. We really don't do well in those scenarios, it would be great if a package that defined such a macro had a way to tell StaticLint.jl what symbols such a macro introduces.

BUT (and this is a huge problem): we can't run arbitrary code from packages inside StaticLint.jl. One core principle is that StaticLint.jl can't crash if there is a bug in a package or user code. So running say a function in a package that would do linting as part of the normal linter code is out of the question for stability reasons. Here are four vague ideas:

1. If we had a purely declarative way of adding linting rules that doesn't require running code. Maybe, maybe this could be good enough to solve for example very simple macro situations where new names are introduced. But probably not even that would work well...
2. We could run these user-provided linting functions in a separate process. Probably way too heavy handed. Also sounds really, really complicated to implement.
3. Maybe we could impose some very strict rules what is allowed in custom linting functions that we can mechanically check and then we still run that code. For example, we could define a whitelist of functions that are allowed to be called from such a custom lint function, and then we would check any custom lint function whether it complies with that and only execute it if all looks ok. But that of course still leaves the door open to things like infinite loops or general crashes, so I'm also not very happy about that... But maybe one could do something with JuliaInterpreter here: run the user code in the interpreter and impose say an instruction limit after which everything gets aborted.

I am not really convinced by any of these, to be honest...