Switch linter to rules

[fzipi]

Right now the linter has all the rules embedded. A simpler way of managing the rules is to create independent files with each check and have them mapped.

Similar to what other linters do.

Requirements

• add a new class LintProblem with the properties used (e.g. line, end_line, description, etc.)
• split the lint rules into files below a rules/ directory
• load the lint rules dinamically from the rules directory. we can even add config levels for each rule, if neded
• every lint rule should yield an error each time we found one, effectively creating an iterator that is easy to use

[fzipi]

Well, maybe I leave this open for now. Probably this would be reusable when we switch to the new parser, but probably investing the time after that would make more sense.

[airween]

What's the main goal?

The new linter is usable and we could replace the old one by this, right? Therefore we should skip this step - but I started to think how should we start it.

I saw your PR #6, but I would approach this step from a different way (I think create a new class for each rule makes more sense, and each classes have the same method where we can call that; then we can pass the main collections to each one, eg. self.globtxvars)

[fzipi]

The main goal is to split each check into smaller files and methods. The idea is to start passing more digested data that checks will find easy to use.

But while another refactor seems useful, I won't invest more time for the time being, as I'm switching to fully focus on getting the new parser done.

[airween]

Right - nevertheless I give a try to make this refactor.