Fix -Wstrict-prototype warnings in HalideRuntime.h

[twesterhout]

When HalideRuntime.h is included in a C file, functions that are declared with () instead of (void) for their arguments change meaning. These may cause issues downstream because different code is generated.

E.g., godbolt example

This PR introduces a HALIDE_NO_ARGS macro that expands to nothing or void depending on whether the code is compiled in C++ or C mode. That way declarations such as function(HALIDE_NO_ARGS) mean "function function receives no arguments" in both C++ and C.
This PR replaces uses of function() with function(void) since function(void) means "function function receives no arguments in both C++ and C"

P.S. this issue was discovered when trying to use Halide with Chapel, but Chapel used -Wstrict-prototypes...

[abadams]

Thanks for the fix

[steven-johnson]

I am deeply confused: how is it possible that () vs (void) can cause different codegen? Don't they have identical meanings in the language (ie: no arguments)?

[steven-johnson]

Additionally, if we must standardize on one or the other, I would vastly prefer that we choose () rather than (void) since the former is what is enforced by our clang-format/clang-tidy ruleset (and I'm surprised that this PR landed without them complaining)

[twesterhout]

@steven-johnson they have identical meaning in C++ and C23 (and newer), but not in C11 and older versions of C. I guess the idea of HalideRuntime.h is to be usable from both C++ and C, hence the choice of (void) in the PR. The godbolt example shows that if compiled as C++, () and (void) generate the same code, but if compiled as C, the generated code is different (this was very surprising to me as well, but was pointed out originally by folks from Chapel's compiler team).

[steven-johnson]

OK, I see now, they are equivalent in C++ but officially-obsolescent-but-still-legal C means "any kind of args", sigh, sorry for the noise