gr: Fix type of OnDemoInit callbacks

[r-burns]

These callbacks can be called with a non-0/1 argument via fn_80169444, so the argument can't be a bool.

[decomp-dev]

Report for GALE01 (3bf5523 - b355b88)

No changes

[ribbanya]

It's seemingly an enum and not a ground segment.

[ribbanya]

If we're refactoring anyway we should make an enum with values 0, 1, and 2.

[r-burns]

This has been up for a while so let me clarify where I'm at. This is a good point that I hadn't originally considered - since you made me aware of that, I've intended to do the bool -> enum_t refactor, but need to look into a method to enforce this a bit better, if possible. Seems simple but has some sticking points!

The bool -> int refactor is motivated by the "native build" CI check where "bool" is a proper primitive type, rather than being aliased to int as in the MWCC build, so this PR is actually needed to widen the native build check to gr/ code. You should be able to reproduce this yourself; try widening the native-build CI check to some existing gr/ files by adding them to .nix/CMakeLists.txt and noting the invalid cast compiler errors. That's all I did here; enable the native-build checks on the gr/ code, then make the code satisfy the stricter compiler.

Properly refactoring int -> enum_t here would be a bit wider than the existing diff, I think, because AFAIK there are some existing callbacks taking int. Since C doesn't have "strongly-typed" enums, an enum_t is the same as an int, so we don't have the benefit of out-of-the-box compiler warnings. Instead, to properly propagate this re-typing, we've got to introduce a new linter check that enforces enum_t -> int conversions, and similarly blocks bool myfunction(int arg) from being set as a callback that expect bool (*)(enum_t arg). Ideally, we'd even distinguish the generic placeholder enum_t from more specific enums we've created, so that once we narrow this to MyCallbackEnum, we can enforce that any called functions are properly typed as bool (*)(MyCallbackEnum arg) and using the appropriate enum values as needed. This would be a really good correctness guarantee for other parts of the code as well, since we have a lot of similar weakly-typed-C-enum usage, so I think it's worth looking into.

So basically, this is still valid and important, but has turned into a big yak shave that I'll need to set aside some time to look into 😉

[ribbanya]

Yeah that makes sense, and I was suggesting a specific placeholder enum definition rather than enum_t (which I'd like to start phasing out anyway). I think there is a clang-tidy check for this besides just readability-magic-numbers but I'll have to dig around for it.