build: Allow non-strict aliasing and overflow optimizations

[jcm93]

Non-strict aliasing is found to resolve #1737.

We also use signed integer overflow around ares, so we want to allow the compiler to optimize for that if it wants to; essentially everywhere ares runs is two's complement.

Couple quirks: Xcode has its own declaration for strict aliasing, so use that. Clang-CL doesn't transparently accept -fwrapv, so it's passed with /clang:-fwrapv.

_ares_gcc_common_options will eventually see more development to make warnings consistent across platforms where possible.

(Fixes #1737)

[DiscoStarslayer]

Can confirm this branch builds fine and fixes the graphical issues on n64 for me on windows + msys2 mingw64 gcc

[TesseracT33]

I have no say in this matter but my opinion is this: instead of using -fno-strict-aliasing, which will probably lead to reduced runtime performance and is more like a workaround rather than a proper fix, one should find where the strict aliasing is violated using a sanitizer and fix the problem from that end instead.

[jcm93]

I could keep strict aliasing under clang since there do not seem to be any environments yet where it causes issues. That might indeed be prudent.

In my first attempts at debugging this problem last month I did try to use ubsan to investigate, but it crashes nearly instantly on my arm64 Fedora system and I was unable to make it cooperate.

clang's sanitizers on macOS meanwhile did not detect any issues that seemed relevant. The only instances of UB it found were negative left shifts in some interpreters:

ares/n64/cpu/interpreter-ipu.cpp:65:44: runtime error: left shift of negative value -31
ares/n64/rsp/interpreter-ipu.cpp:51:50: runtime error: left shift of negative value -2
ares/n64/rsp/interpreter-vpu.cpp:1334:34: runtime error: left shift of negative value -1
ares/n64/rsp/interpreter-ipu.cpp:38:45: runtime error: left shift of negative value -883
ares/n64/cpu/interpreter-fpu.cpp:420:54: runtime error: left shift of negative value -7

etc.

These occurred relatively seldom; far from every frame, and didn't seem directly pertinent to the display output in a way that might cause this issue.

So I'd welcome the approach and do favor it, I just have limited ability to investigate myself.

For whatever it's worth, I went looking and Near's comments contemporary to its introduction can be found here.

[LukeUsher]

One thing at a time; baby steps, we'll take it for now