<complex>: arm64_neon.h declares many non-_Ugly identifiers/macros

[StephanTLavavej]

While performing surgery on #935 to make it header-only for /clr:pure compatibility, I made <complex> drag in arm64_neon.h:

STL/stl/inc/complex

Lines 23 to 32 in 19c683d

	#elif defined(_M_IX86) || defined(_M_X64)
	#define _FMP_USING_X86_X64_INTRINSICS
	#include <emmintrin.h>
	#include <isa_availability.h>
	extern "C" int __isa_available;
	extern "C" __m128d __cdecl _mm_fmsub_sd(__m128d, __m128d, __m128d);
	#elif defined(_M_ARM64)
	#define _FMP_USING_ARM64_INTRINSICS
	#include <arm64_neon.h>
	#endif // ^^^ defined(_M_ARM64) ^^^

@statementreply observed that arm64_neon.h declares a zillion non-_Ugly identifiers and macros.

We should consider doing something about this. Possibilities:

• @CaseyCarter suggested extracting a small subheader (possibly into intrin0.h itself) with just what the STL needs. This would also be good for x86/x64 emmintrin.h.
• Wait for vNext and after /clr:pure is erased from human memory, go back to @statementreply's original separately compiled design, which avoids this identifier pollution.
• Hybrid approach: Continue to use the header-only, non-intrinsic code for /clr:pure, but separately compile the intrinsics for use by native and /clr code. (The only reason I didn't try this was time pressure.)

[frederick-vs-ja]

This seems fixed by #4695.

[CaseyCarter]

This seems fixed by #4695.

Confirmed, we have no remaining inclusion of arm64_neon in the codebase. Let's call this resolved.