[Request] use constants for linter error levels

My team has forked this project a couple times because linting rules are mostly 2/error instead of 1/warning, so it obscures genuine errors.

Something like this:

```
// props sorted wrong
```

Should not have the same severity as a critical bug! This adds a ton of mental overhead to every line when red dots are popping up everywhere: "will this code throw an error or is there some minor formatting issue?"

Needing to be so precious with every line slows down development when you may just be testing some additions or wading into third party code.

Doubly with autofix enabled, Atom currently fixes a ton of formatting inconsistencies on save, I can safely ignore some warnings now.

However, I understand your logic in #853 – when you need to enforce absolute consistency in your team, saying "you can't proceed without fixing this niggle" is important. I would argue that should go in a commit hook or similar, but...

why not use a custom constant to define the error levels? This would allow the linting logic to be more flexible:

`{ rule: airbnb.ERROR }`

Start by reviewing how this project represents linting rule severities and how rules are configured, including the proposed `{ rule: airbnb.ERROR }` form. Determine whether configurable warning and error constants are feasible, then define done as documented, consistent severity behavior without changing the existing enforcement option discussed in #853.

Written by the indexing model from the issue text.