Use strict prototypes on primitives in bytecomp

[MisterDA]

Earlier this year, we enabled warnings for strict prototypes in C code (mostly replacing f() declarations with f(void)). This led to fixing the primitives' list generation; see #11763 and #11861 for history.
clang has started raising warnings by default when it encounters such K&R declarations.
We didn't catch that there was another place generating the list of primitives: the bytecode compiler when it builds a complete executable!
The first commit brings the bytecomp to generate the code we've agreed on from the previous PRs, with the additional twist that we must prevent two functions from mlvalues.h from being re-declared with conflicting types. This is done with some preprocessor tricks inspired by what we already do with ATOM and ATOM_WS.
We can't extract the original types of the primitives, the bytecomp uses its Dll module to check whether a symbol exists in a dll, and types aren't retained.

Side dishes are switching to quoted strings for C code: note how it's nice now. Backslashes can be a bit confusing when dealing with macros, too. edit: although looking at a recent issue, I wonder if this can introduce end-of-line problems between Windows and other systems.

I think we can also constify the primitive lists, right?

I wonder if we can make caml_data, caml_code, and caml_sections const in the generated C code for the complete bytecode executable.

[MisterDA]

Side dishes are switching to quoted strings for C code: note how it's nice now. Backslashes can be a bit confusing when dealing with macros, too. edit: although looking at a recent issue, I wonder if this can introduce end-of-line problems between Windows and other systems.

It does, so I've removed this commit.

[xavierleroy]

Well spotted, thanks! You may have constified less than you thought, see below.

[MisterDA]

Thanks for the review, I've applied your suggestions.

[xavierleroy]

Looks good to me. The #define dance for the two declared primitives is not great but does the job, and I cannot think of a simpler solution. Good to merge!

[MisterDA]

@Octachron It's a bit late, but: can we consider this for 5.1 too? Note that the same patch for the compiler, in the compiler, has been merged since January in #11861. Apple clang 14 defaults to GNU C 17, and generates warnings for this error every time a bytecode executable is built. This can be quite confusing to users, and often pollutes the result of test suites using bytecode executable on macOS.

$ ocamlc -output-complete-exe test.ml -o test.exe
/var/folders/2b/tnr5m72917v6y0qd_7wts3c00000gn/T/camlobjcfc870.c:1521:14: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
extern value caml_get_public_method();
             ^
/var/folders/2b/tnr5m72917v6y0qd_7wts3c00000gn/T/camlobjcfc870.c:1723:14: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
extern value caml_set_oo_id();
             ^
2 warnings generated. 

[Octachron]

Considering that this is the kind of changes that would warrant an opam patch on the compiler for the sake of compatibility, I agree that this should be cherry-picked to 5.1.0 .