Fixed astcenc.h for C builds and double definition of NOMINMAX

[m256i]

Firstly, i could not determine if full C compatibility was intended for this repository, so i want to apologize if it was not.

issues

• <astcenc.h> unconditionally includes <cstddef> and <cstdint> which are C++ exclusive headers.
• the struct and union definitions in <astcenc.h> are not typedef'd to global scope which makes most struct and function definitions ill-formed in a C context
• extern "C" is used unconditionally in <astcenc.h> with ASTCENC_DYNAMIC_LIBRARY which is also invalid C
• NOMINMAX is defined twice under my build system (ninja 1.11.1 + MinGW UCRT64 gcc 15.1.0)

These changes are ABI BREAKING since C++ name mangling/linkage for all API exposed functions in <astcenc.h> get disabled with this commit.

changes

• wrapped c++ only includes <cstddef> and <cstdint> around #if defined(__cplusplus), use C compat versions otherwise
• additionally included <stdbool.h> for C builds
• added ASTCENC_EXTERN_C macro that evaluates to extern "c" only for C++ builds
• wrapped #define NOMINMAX into a guard that prevents double definitions

Perhaps i should add a "ASTCENC_C_COMPAT" flag to the CMake build file to avoid a forced ABI change for all users?

I have tested building the library with these changes on both C and C++ compilers with success. I am open to any other approach that the maintainers prefer, if C compatibility IS intended :)

[solidpixel]

Full C compatability wasn't something I originally aimed for - the extern "C" declarations are there so there is a stable compiler-independent name for resolving at run-time though dlsym().

I'm very happy to support it if you need it though, it's not going to cost anything in terms of complexity or performance.

[m256i]

Hi,
Im very sorry for responding so late.
dedicated C support would be amazing! However i forgot to mention that
linkage for the entire library right now seems to be dependent on c++'s runtime library (i.e i need to link -lstdc++ for it to compile in my C setup) which is a bit akward. If you want i can add to this PR but im afraid that it might make some more ABI breaking changes especially in the cmake configuration.Let me know how you’d prefer to proceed.

[solidpixel]

The core library is written in C++, and that isn't going to change.

I do want to ensure is that a standard's compliant C program can use the astcenc.h interface header, but if it doesn't want to link any C++ directly, it would need to load astcenc as a shared library using dlopen/dlsym. This is quite a common usage model anyway, given that it allows you to dlopen the "best" library in terms of the SIMD option that the running CPU supports.