Improve Glk C++ compatibility

[cspiegel]

I've run into a couple issues while working with Glk in C++.

1. The Glk ABI is C (no mangled names), but the provided glk.h header (at https://www.eblong.com/zarf/glk/glk.h) provides C++ (mangled) names when used with a C++ compiler. Client code can, of course, wrap the include in extern "C", but it would be very convenient if instead glk.h itself had such a declaration, wrapped in #ifdef __cplusplus.
2. There are many functions which accept a char * parameter where const char * would be preferred. This is actually not strictly a C++ issue, given that it's reasonable in C to use const char * for safety, and then be forced to cast to char *, but it's more pronounced in C++ where string literals have type "array of const char" instead of "array of char".

I request that the offical Glk header file be updated to be more friendly to C++. These changes shouldn't affect existing programs which make use of Glk, except perhaps if a pointer to one of the char *-accepting functions is being stored... but that's probably unlikely, and would be easy to change.

[erkyrath]

Adding extern "C" is reasonable.

Adding const is a well-known headache. It pretty much requires going through every library and interpreter and const-ing them, all in one release. This is a lovely idea, but wow, I don't see myself sitting down to do it.

[cspiegel]

Great news on extern "C", thank you!

As for const, I don't think it will affect interpreters: they're already passing unqualified char * (or glui32 *) by necessity, and that will be compatible with const char *, The only weird cases would be where they care about the exact prototype, e.g. if doing something like:

void (*put_string)(char *) = glk_put_string;

That will become invalid, and while it's probably not something anybody is doing, it's possible. It's also a trivial fix, but if it's being used in the wild, I can understand trepidation in forcing a change.

But I understand that it's a big job. If it's at least something that might be acceptable, I'm willing to do the conversions to see what kind of problems might occur, and if you deem it acceptable, I'd provide pull requests/patches. If it's a hard "no" then I won't bother taking the time, but otherwise I'd find it worth trying, even if the end result is to keep the status quo.