Use _GLF_LIVE(...) macro to make live-injected loops and other constructs easier to identify

[afd]

948 improves the way in which the reducer eliminates loops that contain loop limiters.

However, their removal still depends on being able to identify a loop as being live-injected, and a problem remains related to this.

A loop is identified as live-injected if its guard (or increment, in the case of a for loop) contains a reference to a live-injected variable (that is not under a fuzzed macro).

However, if the loop's guard has already been simplified by the reducer to a constant, it will not be identified as live.

So we may end up not being able to remove a loop such as:

GLF_live_limiter = 0;
while (true) {
    if (GLF_live_limiter >= 5) {
        break;
    }
    GLF_live_limiter++;
}

Instead of working on this in the reducer, I propose that we change the generator so that the conditions of loops, conditionals and switch statements introduced during live code donation are changed to use a macro, _GLF_LIVE(...). We would stop the reducer from simplifying this macro (but it could simplify the macro argument).

Then the above loop into while(_GLF_LIVE(true)), and there would be no problem identifying it as live.

Doing the same for if and switch statements is independent from issues related to loop limiters, but it makes sense to make the fact that such statements are live-injected easier to discover.

[afd]

@paulthomson for info.