aarch64: Fix for support of xonly

[brad0]

OpenBSD 7.3+ requires xonly.

[brad0]

cc @mstorsjo

[mstorsjo]

FWIW, this patch breaks compilation for aarch64 for essentially every configuration concievable, as is.

With Clang:

codec/common/arm64/mc_aarch64_neon.S:35:1: error: unknown directive
.rodata
^
codec/common/arm64/mc_aarch64_neon.S:38:1: error: unknown directive
.previous
^

With binutils:

codec/common/arm64/mc_aarch64_neon.S: Assembler messages:
codec/common/arm64/mc_aarch64_neon.S:35: Error: unknown pseudo-op: `.rodata'

Switching to the .rodata section (or whatever the suitable thing on each OS is) probably needs to be wrapped up in macro in codec/common/arm64/arm_arch64_common_macro.S; based on e.g. corresponding macros in ffmpeg, it needs to be .section .rdata on Windows, .const_data for mach-o/apple and .section .rodata for the others (which I presume would work on OpenBSD as well). Then instead of .previous, we can probably either switch back to .text in an end macro for rodata sections, or add .text to WELS_ASM_AARCH64_FUNC_BEGIN.

Then finally, for MSVC build configurations, we normally use clang for building the assembly, but we used to use gas-preprocessor earlier. (Using gas-preprocessor allows using MSVC's armasm64 assembler tool, and avoids requiring two separate compilers.) In such configurations, it seems like gas-preprocessor doesn't handle cases like ldr q22, [x6, #:lo12:filter_para] - but I guess that that aspect is up to me if I want to fix gas-preprocessor to handle it, as openh264 itself doesn't normally use that configuration for MSVC builds.