Consider NaN falseish

[dcodeIO]

fixes #770
fixes #787

This is mostly identical to #787 but also removes some internal patterns prone to errors when dealing with temporary locals as it was hard to grasp if code would "just work" otherwise.

In particular, flows had a getAndFreeTempLocal helper that immediately free'd a local intended for one-time use, which can lead to subtle errors where sub-expressions might reuse the same local. Hence I decided that even if code looks more cumbersome without it, that it's worth to require holding on to a temp as long as another make* function might reuse the same, so it's pretty much guaranteed that even if we update codegen in between a getTempLocal and a freeTempLocal in the future the resulting code will keep working.

I've also looked over all the occurrences of makeIsFalseish and makeIsTrueish which all seem to be fine, adding the local to the flow being responsible. The notable ones here are those of anything if-like where the condition temp locals go to the outer instead of one of the inner flows.

cc @MaxGraey

[MaxGraey]

LGTM

[dcodeIO]

Last commit also eliminates makeIsFalseish which was used only once when compiling !x, that is essentially "not is trueish" anyway.

[dcodeIO]

Last commit makes isNaN and isFinite builtins again. Leads to slightly more code but also guarantees that these precompute at some places, which might be beneficial in static branch elimination. cc @MaxGraey wdyt?

[MaxGraey]

I think this problem need solve via enhancing inlining limits. Yes we could improve isNaN and isFinite but this not solve problem with user space which still required manual inlining. Also I wonder how this better than simply add @inline decorators?

[dcodeIO]

It's slightly more efficient than @inlineing since it doesn't create a block with aliased locals, but functionally equivalent and should yield about the same optimized code. Both would precompute.

[MaxGraey]

Found one missing part. When we have casting from float to boolean like:

function cast(x: f64): bool {
   return bool(x);
}

it becomes:

return x != 0;

without isNaN check. So perhaps better implicitly transform to !!x for floats. WDYT?

[dcodeIO]

Hmm, yeah, that's odd. Not sure what you mean with !!x, though. Looks like this needs to be handled on codegen level?

[MaxGraey]

Not sure what you mean with !!x

Oh, mean it just should generate same code (x != 0.0) & (x == x)

[dcodeIO]

Oh no, I spot a temporary local there. But yeah, guess this can't be avoided :)