Allow `enable` to override `severity`

[scop]

For bugs

• Rule Id (if any, e.g. SC1000):
• My shellcheck version (shellcheck --version or "online"): 0.7.1
• [ ] The rule's wiki page does not already cover this (e.g. https://shellcheck.net/wiki/SC2086)
• [ ] I tried on shellcheck.net and verified that this is still a problem on the latest commit

For new checks and feature suggestions

• [ ] shellcheck.net (i.e. the latest commit) currently gives no useful warnings about this
• [x] I searched through https://github.com/koalaman/shellcheck/issues and didn't find anything related

Here's a snippet or screenshot that shows the problem:

#!/bin/bash
i=0
(( $i++ ))

Here's what shellcheck currently says:

$ shellcheck -f gcc -S warning -o SC2004 test.sh
# doesn't say anything

Here's what I wanted or expected to see:

$ shellcheck -f gcc -S warning -o SC2004 test.sh
test.sh:3:4: note: $/${} is unnecessary on arithmetic variables. [SC2004]

It would be good to be able to enable additional messages on top of severity limits. For example I'd like to use the warning or info severity level but still additionally be notified about SC2004. I'd expect this to happen when I specify e.g. -S warning -o SC2004, but currently it appears the severity level does not take additional explicit enables into account.

[TinCanTech]

Similar to #1417

[HalosGhost]

This makes a lot of sense to me as how things ShouldWork™. In particular, it's a bit of a surprise that -i/-e/-o, which are more specific than -S don't always take precedence.

Ideally, given that shellcheck already has an established precedence order (e.g., -i overrules -e), -i/-o would overrule -S (as -e already does). This is, in some sense, an API change, and so could potentially cause breakage. However, the behavior now is quite unintuitive (and the only cases which would “break” are those where people have been specifying -i/-o with an incompatible severity level; previously, they would receive no diagnostics, and now would have fixes to apply)—it wouldn't surprise me if most breakages were effectively “silent failures” before. This strikes me as a bug-fix.