feat: 'inconsistent types' warnings as errors by default

[Kamirus]

What?
Makes 'inconsistent type' warnings as errors by default (minor breaking change, fixable by -W moc flag):

"M0061", "Comparing abstract type to itself at supertype";
"M0062", "Comparing incompatible type at common supertype";
"M0074", "Array elements have inconsistent types";
"M0081", "If branches have inconsistent types";
"M0101", "Switch with inconsistent branch types";
"M0166", "Type intersection results in abstract type";
"M0167", "Type union results in bottom type";
"M0190", "Types inconsistent for alternative pattern variables, losing information";

Why?
Caffeine needs to treat these as errors. However, it makes sense now (since we have a way to modify the lint level) to actually treat them as errors by default. IMO all of the above messages are type errors that signal a bug in the code

To avoid breaking change without modifying the code pass the following flag to moc
-W M0061,M0062,M0074,M0081,M0101,M0166,M0167,M0190

[Kamirus]

Here is the list of warnings that I'd treat as errors by default

"M0061", "Comparing abstract type to itself at supertype";
"M0062", "Comparing incompatible type at common supertype";
"M0074", "Array elements have inconsistent types";
"M0081", "If branches have inconsistent types";
"M0101", "Switch with inconsistent branch types";
"M0166", "Type intersection results in abstract type";
"M0167", "Type union results in bottom type";
"M0190", "Types inconsistent for alternative pattern variables, losing information";

[github-actions]

Comparing from 5198962 to cf446a4:
In terms of gas, no changes are observed in 5 tests.
In terms of size, no changes are observed in 5 tests.

[crusso]

I dunno, seems a bit odd to rule out something that doesn't actually go wrong.

Doesn't caffeine compile with warnings as errors anyway?

[Kamirus]

Doesn't caffeine compile with warnings as errors anyway?

Not every warning, no. They would need to switch all these flags.

I dunno, seems a bit odd to rule out something that doesn't actually go wrong.

1. It delays errors, typechecks as Any in one place, raises an error later.
2. Leads to bugs when Any is later compared using ==, does not go wrong typing-wise, but very wrong at runtime
3. We cannot use Any in any meaningful way, we have no downcasting. I'd treat resolving Any as the best common type (LUB) as error (it would help with bimatch errors too, but that is a separate story, not this PR), and only allow it with an explicit annotation : Any (in check_typ path)