Add 'void' to clear strict-prototype warnings

[brturn]

When building on my machine, a LOT of "strict-prototype" warnings are generated (hundreds). This PR fixes them, and should have no in-game effects.

My compiler:

cc --version
Apple clang version 17.0.0 (clang-1700.6.3.2)
Target: arm64-apple-darwin25.2.0
Thread model: posix

This is a largely automatic refactor, the majority of these changes can be found using a find/replace regex:

find: ^(.*)\(\) \{
replace: $1(void) {

The last few are in platform.h added manually.

[tmewett]

To understand: what's wrong with the empty () ? Is it that you can call it with arguments but they will be ignored?

[brturn]

It's a deprecated declaration syntax (for as long as I can remember, actually). Unspecified parameters tells the compiler not to check for parameter mismatches. Providing the explicit list of parameters ensures that the compiler can verify that callers are providing the correct number and type of parameters. For functions with zero parameters, the "explicit list" means specifying "void". C++ fixed this by making "()" equal to "(void)", but C has not adopted this due to incompatibility with existing code styles.

src/brogue/Time.c:1946:35: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
 1946 | static void monstersApproachStairs() {
      |                                   ^
      |                                    void

[tmewett]

Ok, thanks - given that I don't think this has ever caused an issue for us, there is an argument that we just silence the warning. However I'm fine with fixing them too, but if we do I think we should make it an error with -Werror=strict-prototype because there's no reason we'd ever want to do it

[brturn]

Ok, thanks - given that I don't think this has ever caused an issue for us, there is an argument that we just silence the warning.

Totally fine either way. It was the squeakiest of them on my machine and turned out to be easily corrected.

If you'd rather silence them, I can open a separate PR with that change.

However I'm fine with fixing them too, but if we do I think we should make it an error with -Werror=strict-prototype because there's no reason we'd ever want to do it

Agreed. I've updated the PR to add strict-prototypes to the errors list, and sorted the cflags to make it easier to see which flag is in which grouping.

[nstoddard]

I'm in favor of adding (void) here. A while back, in #593, I added (void) to prototypes, which was apparently necessary for a warning to work properly. This PR makes function definitions look more similar to the prototypes, and I'm in favor of keeping them consistent.