Consider using go/analysis as a model for refactored noverify structure

[quasilyte]

Idea: adapt go/analysis for NoVerify as an interface for checkers implementations ("custom checks").

---

Rationale: make builtin checks and cache/meta mechanisms less bound with each other. Right now external checkers are limited. We need to extend existing "custom" checks API.

---

We can take a go/analysis framework as an example. It's now quite mature and was developed with a lot of tool authors feedback. With some thoughts, it can be ported to suite NoVerify causes.

At least we can borrow:

• Terminology.
• The idea of stages separation (passes).
• The methods of stages composition.
• And other architecture concerns regarding linters construction.

Note that we don't want to port 100% of its functionality. That would be impractical. But the parts we're going to port could be as close to the "reference" as possible. And then we can extend in the same way by porting other parts as they're required.

Potential problems:

• Cache. I'm not 100% sure analysis handles it right now (I might be wrong).
• More overhead. Can be potentially solved with appropriate optimizations when we prove that a new version is sluggish.

The other approach is to extend what we currently have. This can work as well, but the research on go/analysis can help to understand the domain better.

[YuriyNasretdinov]

Current implementation of custom linters was implemented post-factum, without much thought put into it. I think it's not a bad idea to try to implement something more mature and (probably) resembling the "go way" in go tools.