cmd/compile: for rangefunc, add checks and tests, fix panic interactions

Modify rangefunc #next protocol to make it more robust

Extra-terrible nests of rangefunc iterators caused the
prior implementation to misbehave non-locally (in outer loops).

Add more rangefunc exit flag tests, parallel and tricky

This tests the assertion that a rangefunc iterator running
in parallel can trigger the race detector if any of the
parallel goroutines attempts an early exit.  It also
verifies that if everything else is carefully written,
that it does NOT trigger the race detector if all the
parts run time completion.

Another test tries to rerun a yield function within a loop,
so that any per-line shared checking would be fooled.

Added all the use-of-body/yield-function checking.

These checks handle pathological cases that would cause
rangefunc for loops to behave in surprising ways (compared
to "regular" for loops).  For example, a rangefunc iterator
might defer-recover a panic thrown in the syntactic body
of a loop; this notices the fault and panics with an
explanation

Modified closure naming to ID rangefunc bodies

Add a "-range<N>" suffix to the name of any closure generated for
a rangefunc loop body, as provided in Alessandro Arzilli's CL
(which is merged into this one).

Fix return values for panicky range functions

This removes the delayed implementation of "return x" by
ensuring that return values (in rangefunc-return-containing
functions) always have names and translating the "return x"
into "#rv1 = x" where #rv1 is the synthesized name of the
first result.

Updates #61405.

Change-Id: I933299ecce04ceabcf1c0c2de8e610b2ecd1cfd8
Reviewed-on: https://go-review.googlesource.com/c/go/+/584596


Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Tim King <taking@google.com>