Add IsDefined builtin and AddToPool/#pool

[StanHash]

They work essentially the same way they did in legacy EA.

• IsDefined(Name) expands to 1 if a definition or macro (why are those different things) of given name exists, expands to 0 otherwise.
• AddToPool(tokens...) expands to the name of a label referring to data described by the listed tokens (that would be pooled by a subsequent #pool directive).
• AddToPool(tokens..., Alignment) is the same as above, with the additional guarantee that the pooled data will be aligned with requested Alignment. This one is isn't in legacy EA.

Pool stuff is still a bit jank as pool labels are still affected by scope shenanigans (so in order for all of this to work, the #pool directive needs to be in a label scope that is visible to the AddToPool macros). We could make this slightly better if #37 gets implemented. Dumped pooled data is now parsed as if label scope is the same as the one from the AddToPool expression.

Pool labels are internally under the form __POOLED$<number>. They have a $ character in them to guarantee no user label can conflict with pool labels.

(I need to figure out how I can expand full expressions within builtin macros so I can implement more of the old stuff (Stuff like Signum, Switch, and maybe a variant of IsDefined that takes a second integer parameter that checks for a macro with that parameter count specifically)).

[StanHash]

I just kind of want to be able to do things like this:

#ifndef PooledRedaDefined
    #define PooledRedaDefined
    #define PooledReda(X, Y) "AddToPool(REDA [(X), (Y)] 0 0 0 0)"
#endif // PooledRedaDefined

// [Whatever Chapter Things]

scSomeReinf: {
    SPTR s2 unUnits
    CALL scLoadReinforcements

    NoFade
    ENDA

unUnits:
    UNIT [...] 1 PooledReda(x1, y1) [...]
    UNIT [...] 1 PooledReda(x2, y2) [...]
    UNIT

}

scSomeReinf2: {
    SPTR s2 unUnits
    CALL scLoadReinforcements

    NoFade
    ENDA

unUnits:
    UNIT [...] 1 PooledReda(x3, y3) [...]
    UNIT [...] 1 PooledReda(x4, y4) [...]
    UNIT

}

// [More chapter things]

#pool

Having a pool at the end of each scope here would be annoying to the user imo, and I don't think it makes things any clearer or safer (again, to the user).

EDIT: Also to be somewhat consistent with nl!EA behaviour, which allows this.

[Crazycolorz5]

Makes sense. So we want to allow for bleeding out of scopes... But there is the issue you mentioned before about pooling something that refers to a local label. And I can see error messages from that being more cryptic (as the user, you'd see the variable defined/bound RIGHT THERE)

I think personally it makes more sense to force more often pooling rather than have cases that hace issues like that.

Edit: I'm okay with diverging from original EA behavior on this one because a) it wasn't commonly used b) it had a lot of issues (which is what we are pointing out with it right now). B probably contributed to A tbh.

[StanHash]

I fixed that in my last commit (pooled statements have the scope of the AddToPool expression, not the #pool directive)

[Crazycolorz5]

Ah, I misunderstood your fix. So each pooled line gets parsed as if in the closure of its original AddToPool, then the pooled label gets added into the global namespace?

Hm, yeah I guess that works.

[StanHash]

The pooled label gets into that same scope too (as the label definition is just part of the pooled statements).

[Crazycolorz5]

going back to add things into the scope seems unintuitive to me (as there's no other language mechanism to add definitions to a scope once outside it), but again, pooled labels are referred to at only one location, so there shouldn't be any fishy behavior from it