Resolves #8573

Changes:

• So the problem here is that ifs and fors determine what updates each loop/branch based on parsing of = statements. But calling .set(...), a new construct, doesn't get noticed as part of that.
• Rather than doing a refactor to handle = OR .set() calls in loops and branching, instead this transpiles away .set() calls in loops/branches to use an intermediate variable outside the loop, assign to it normally inside the loop, and then call .set() on the result at the end.
• Also fixes an issue with let something; intermediate variables that don't have a type. Previously they worked only if you use them as a "flat" dependency, i.e. you assign them directly with a value. If you have a conditional update where you assign it to either itself or a real value, then we get a nested dependency, and it breaks. So now we recursively update types when you do that, so that all nested dependencies get type info.

Screenshots of the change:

Live: https://editor.p5js.org/davepagurek/sketches/iY_hzGaAj

PR Checklist

• npm run lint passes
• Inline reference is included / updated
• Unit tests are included / updated