only allow re-raise in scope of except

[zerbina]

Summary

Treat a re-raise (i.e., raise without operand) as a compile-time
error when used outside of the scope of an except clause -- re-
raising from within a finally clause that's within the scope of an
except clause is disallowed too.

This brings the re-raise feature into a "safe" state, where it can be
extended from again if wanted/needed.

Details

If a re-raise is allowed from anywhere, it is possible to handle an in-
flight exception from within a finally clause:

try:
  raise CatchableError.newException("")
finally:
  try:
    raise # re-raise the in-flight exception
  except:
    # handle the exception
    discard

Since the exception is handled, control-flow would have to "fall out"
of the finally clause, but this violates the expectations of control-
flow analysis in the compiler as well as those of the code generators.
There, the expectation is that if a finally clause was entered
through exceptional control-flow, raising continues when the end of
the finally is reached.

Until it's clear if, how, and under what circumstances this should
work, a finally clause handling the in-flight exception is prevented
by restricting re-raise statements to the scope of except clauses.
sempass2 implements the detection and error reporting.

The manual is updated accordingly and tests for the new behaviour are
added.

Usage

In the compiler's repository, re-raising from outside the scope of an
except clause was only done by two tests. For one of them, the re-
raise can safely be replaced with a normal raise.

The other test explicitly tested the "re-raise in finally" case. It is
removed for now.

[saem]

Minor suggestion for additional test coverage, but perhaps it's sufficiently covered in tfinally6.exceptionInFinally -- feel free to ignore it.

[zerbina]

/merge

[github-actions]

Merge requested by: @zerbina

Contents after the first section break of the PR description has been removed and preserved below:

---

Notes for Reviewers

• the strategy and problem were discussed here