Add tests for re-binding

[codesections]

On 2021-11-08, I merged rakudo/rakudo#4536, which corrected Rakudo's handling of re-binding to better fit the behavior described in S02, S06, and S07 (see that issue for background). At that time, @vrurg suggested moving the accompanying tests into Roast. However, @raiph had previously +1ed the PR "provided roast isn't being changed" (emphasis added). Since we didn't seem to have full consensus, I held off on adding any tests to Roast.

Having lived with the fixed semantics in Rakudo for a few releases now without apparent issue, I'm proposing this PR, which moves the re-binding tests from Rakudo into Roast, thereby specifying when variables can and cannot be rebound.

Here's a description of the behavior specified by these tests (though, of course, the tests themselves, not this description, are what would become the spec):

• Non-sigiled 'variables' and other terms cannot be rebound
• Sigiled variables that weren't declared as part of a Signature can be rebound
• Sigiled variables that were declared as part of a Signature can be rebound only if declared with is copy or is rw

For the above "declared as part of a Signature" covers two cases:

• function declaration: sub f($a, $b) { }
• The signature that is created when a parenthesized expression is used as :='s LHS in a variable declaration (see S02, spec'ed in S02-names-vars/signature.t: my ($a, $b) := (42, 47);

[vrurg]

Something more of a problem-solving, but two details I have missed earlier.

Code:

my &f := sub () { say "1" };
f();
&f := sub () { say "2" };
f();

Why not? I don't see what kind of problem does it prevent. And why would it be different from, say my @a := [1,2]; @a := [3,4]?

Semantics of is rw allowed for re-binding is also dubious. It's purpose is also to restrict arguments to writable containers. Otherwise it is the same is is raw. When re-bound it looses connection to the original container – thus, looses it's purpose.

UPD. Of course, forgot to mention that I appreciate moving these into roast. :)

[raiph]

Having lived with the fixed semantics in Rakudo for a few releases now without apparent issue, I'm proposing this PR, which moves the re-binding tests from Rakudo into Roast, thereby specifying when variables can and cannot be rebound.

Thanks for A) this stellar work and B) stellar care about the process.

Is this a proposal for 6.e or current Raku?

Also, are you familiar with the outstanding 6.c to 6.d process Zoffix led in 2017/2018?