Helping hand from order of messages: causes and consequences

**Is your feature request related to a problem? Please describe.**

When there are lot of error messages, like in a refactoring attempt, the order of messages is important.

A sample case for illustration:

```python
def main() -> None:
a = b()
```
`b` is not defined, so obviously it is wrong and the real issue is there.

PyRight shows it as:

```
test.py
test.py:2:5 - error: Type of "a" is unknown (reportUnknownVariableType)
test.py:2:5 - error: Variable "a" is not accessed (reportUnusedVariable)
test.py:2:9 - error: "b" is not defined (reportUndefinedVariable)
3 errors, 0 warnings, 0 informations
```

I know it's not easy: the cause or the consequence first? An error is a consequence, so it may seems obvious consequences are to comes first. But since a cause can have multiple consequences, to designate the cause first may be a better helping diagnostic. This make me think or syntactic error, where a single missing parenthesis in a file, can ends into a lon-long list of error messages. I always though it would be better to stop at the first, since it is expected this single error will produce many consequent errors. This behavior depends on the type of error and the amount and scope of the consequences they can have.

From a practical point of view, even Python agrees the first issue is something being not defined.

With this:

```python
A = b()
```

It complains:

```
Traceback (most recent call last):
File "", line 1, in
File "test.py", line 1, in
A = b()
^
NameError: name 'b' is not defined
```

This is why, for each module, I do an import check **before** the type-check.

Also, what can be inferred from something which simply does not exist? Or, is it relevant?

**Describe the solution you’d like**

The log could be instead like this:

```
test.py
test.py:2:9 - error: "b" is not defined (reportUndefinedVariable)
test.py:2:5 - error: Type of "a" is unknown (reportUnknownVariableType)
test.py:2:5 - error: Variable "a" is not accessed (reportUnusedVariable)
3 errors, 0 warnings, 0 informations
```

Or even better:

```
test.py
test.py:2:9 - error: "b" is not defined (reportUndefinedVariable)
this have 1 cascading consequence(s)
test.py:2:5 - error: Variable "a" is not accessed (reportUnusedVariable)
2 errors, 0 warnings, 0 informations
```

The fact something is finally not used, can be an indication solving an error about it is trivial, just removing it. It could come first. But this is more heuristic than formal, this may even be more expected from a linter than a type-checker. Opinions vary about it. Still, what about listing it as:

```
test.py
unused entities:
test.py:2:5: a
test.py:2:9 - error: "b" is not defined (reportUndefinedVariable)
this have 1 cascading consequence(s)
2 errors, 0 warnings, 0 informations
```

This is not an erroneous behavior, this is about clearer view when there a a lot of messages, unlike with this example.

But I don’t consider it as a bug, still thanks for PyRight.

The issue mentions no files, tests, or entry points. Start by reproducing the shown diagnostics for the sample Python snippets, then investigate how diagnostic ordering is currently determined. Done would require an agreed, implementable rule for ordering or grouping causal and cascading messages, along with tests for that behavior.

Written by the indexing model from the issue text.