Proposal: local variables

[McJones]

Rationale

Currently all variables in Yarn are global in scope and require going in and out of the variable storage to be used.
While for the most part this is good, many variables are needed in numerous places and the variable storage system does what it says on the tin and is also easy to use for serialising variables out when saving game.
It is however a bit heavy handed approach for anything that is only needed in the local scope.

Counters are the most obvious of these, many times I have found myself writing code where I either have to be diligent in resetting counters or I find myself writing variables like $counter_white_chat and $counter_joe_chat and making hundreds of essentially unique variables that are all tracked, maintained, despite them all only really existing in the node and could be reused.

Other situations are when creating combined variables such as:

<<if $white_tipped is true>>
    <<if $blue_tipped is true>>
         // four more of these
        <<set $ready_for_heist to true>>
    <<endif>>
<<endif>>

// many lines later

-> Complain about Pink not tipping. <<if $ready_for_heist>>
-> Let's go!

and $ready_for_heist is now only needed to avoid having to write out the check all over.
I know there are other ways around it, such as writing out $white_tipped is true and $blue_tipped is true everywhere or rearranging some code but it feels more natural to declare a variable to track this and to front load the state in a node.

The Proposal

We add in support for local variables.
These would work identically to normal variables except they are only kept around in memory for the duration of their scope.

Creating them

We would have a new variable declaration <<temp $varName is true>> which is the local form of the <<declare $varName is true>> from #260 (name subject to bikeshedding).

Using them

They would work identically to existing variables, and follow all variable rules except they don't go into or managed by the variable storage system.
All existing functions, expressions, and interpolated strings would work fine with them, and from the users perspective require no work from their part to use them.

Scope

For local variables to work we will need to determine the scope of a local variable.
The easiest way to do this is to make scope the node they are declared in.
I think this is going to be the most common case people want to use them anyway, but it might be worth tracking their use and seeing if we can determine the actual scope of local vars and making that the case.
This could also be used to automatically determine variables that are full variables in existing programs and don't need to be.
Once the scope of a variable has been left the variable is freed from memory and is no longer accessible.
Attempting to use a local variable outside of its scope will be a compile time error, not a runtime error.

Implementation

I think we'd either need to implement new op code for the management of local variables or modify the existing op codes so that variables have a location, similar to how I think most register based systems work (not fully checked that though).
Another option is to have these variables checked into and out of the variable storage system but add commands into the program that delete the local ones once their scope ends.
This is less ideal from many perspectives but is probably easier to implement.

Alternatives

The only real alternative to this is doing nothing.
This doesn't solve any massive problems and is more a code cleaning feature than anything revolutionary.

[desplesda]

We'll defer this feature to v2.1; to ensure backwards-compatibility, we'll reserve the keyword that this feature depends upon in v2.0.

My preferred keyword for identifying a local variable is local. Anyone have a strong objection to that?