Fix aliasing _has_include with a custom macro

[martis42]

Fixes #260

Disclaimer: This is mostly based on an analysis with an AI Agent.

[jefftrull]

From my experiments (and the provided unit test) it looks like this only handles object-like macro aliases for __has_include. I may prefer to hold off for a unified solution.

[martis42]

You are right, I missed #if defined BUFSIZE and misunderstood your ask for it. Will add a test case for it an look for a proper solution.

[jefftrull]

I'm happy to take on a fix, also.

[martis42]

You definitely know this code better. My attempt at a logic fix would either way prefer involving an AI Agent.
Did I understand you correctly in #260 (comment) that no further test cases are required, since the same bug is not present for defined?
Then, I think you are better suited to fix this in a more generic way. Feel free to reuse this test case. If I can help you by coming up with other tests, please ping me. I am happy to help insofar I am able to 😀

[jefftrull]

The additional testcase that I think is needed is for function-like macros, i.e.

#define HASINCLUDE(x) __has_include(x)
#if HASINCLUDE(x)
...
#endif

The expansion path is likely to be different than the object-like macros #define HASINCLUDE __has_include.

As for defined() I have convinced myself that the Wave implementation is arguably conforming.

Given that I would have to carefully review any PR for correctness I am happy to write the fix. I will be glad to copy your testcase (and credit you for it). Thanks for the bug report!

[martis42]

I rebased my test case (numbering conflict with #262) and added the requested extra test case. The tests are now an own commit for easier reuse.

I adapted the fix, which would have been green with the new test case. Just FYI, I know you will go your own way for fixing this. The fix is now an own commit for clear separation allowing you your own appraoch.