Make SC1075 a warning

[GfEW]

For bugs with existing features

• Rule Id: SC1075
• My shellcheck version: 0.11.0
• The rule's wiki page does not already cover this
• I tried on https://www.shellcheck.net/ and verified that this is still a problem on the latest commit

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

$ shellcheck --shell=bash  --severity=error <<'EOF'
demo_inline_fun() { local f="$1"; if [[ -f "$f" ]]; then if [[ -r "$f" ]]; then echo "File exists and is readable"; return 0; else echo "File exists but is not readable"; return 1; fi; else if [[ -e "$f" ]]; then echo "Path exists but is not a regular file"; return 2; else echo "Path does not exist"; return 3; fi; fi; }
EOF


In - line 1:
demo_inline_fun() { local f="$1"; if [[ -f "$f" ]]; then if [[ -r "$f" ]]; then echo "File exists and is readable"; return 0; else echo "File exists but is not readable"; return 1; fi; else if [[ -e "$f" ]]; then echo "Path exists but is not a regular file"; return 2; else echo "Path does not exist"; return 3; fi; fi; }
                                                                                                                                                                                         ^-- SC1075 (error): Use 'elif' instead of 'else if' (or put 'if' on new line if nesting).

For more information:
  https://www.shellcheck.net/wiki/SC1075 -- Use 'elif' instead of 'else if' (...

Here's what shellcheck currently says:

^-- SC1075 (error): Use 'elif' instead of 'else if' (or put 'if' on new line if nesting).

Here's what I wanted or expected to see:

^-- SC1075 (warning): Prefer 'elif' instead of 'else if' (or put 'if' on new line if nesting).

Additional context:

The current error message is misleading, as the objected syntax phrase is actually never wrong in bash, contrary to any established notion of an "error".

SC1075 presumably has been classified as an "error" regardless, in order to draw maximum attention to it, just in case the user might misinterpret else if in bash as if it were C.

However, that apparent "pro" argument is in itself even more of a "con", because "error" is the top severity shellcheck has to offer, which should be reserved for true errors in the language/dialect we are actually testing_ (e. g. shell/bash).

Such true error conditions include e. g. incorrect syntax or stuff that breaks when run, as opposed to suboptimal, but perfectly legal syntax labelled "erroneous" on the mere basis it behaves differently in some unrelated, compiled, low level programming language.

Granted, the use of else if vs. elif may constitute a pitfall if you happen to learn bash with prior C knowledge, but that doesn't make it anywhere near an "error" in shell scripting.

The SC1075 alarms falsely raised with --severity=error are not adequately mitigated by pointing out on the wiki page that, and how, you can disable them. (Moreover, following that advice doesn't make the message a proper warning, either, but instead mutes it everywhere - or perpetuates case-by-case tedium.)
else if just shouldn't be misrepresented as an "error" in the first place.