Preserve zero-filled data directives

[zhangzhenghao]

Closes #80

Problem

Compiler-generated constant pools can contain directives that GoAT did not parse. Dropping them shortens generated data symbols, shifts later fields, and can make aligned SIMD loads fault.

The original amd64 failure used .zero. Cross-platform reproduction also found:

• Clang emits .space count[, fill] on several targets.
• GCC emits .base64 "..." for repeated initialized bytes on ppc64le.
• Decoded payloads can have non-power-of-two lengths, while Go assembler only accepts DATA widths 1, 2, 4, or 8.

Solution

• Parse .zero count[, fill].
• Parse .space count[, fill].
• Decode GCC .base64 data directives.
• Emit arbitrary data lengths using legal 8/4/2/1-byte DATA chunks.
• Add one C integration regression under tests that makes target compilers emit these directives and verifies zero bytes, filled bytes, and subsequent field offsets.
• Place the ppc64le fixture values in separate read-only sections so GCC emits independent TOC references.

Verification

• go test ./...
• go vet ./...
• Generated and ran the repository amd64 test suite
• Generated and ran the ppc64le suite locally with QEMU 10.2.1
• Verified the C regression fails against the pre-fix parser and passes with the fix
• Generated and cross-compiled the fixture for arm64, riscv64, loong64, s390x, and ppc64le
• Verified a six-byte symbol emits /4 and /2 DATA records and assembles
• Regenerated and compiled the xvec AVX512 INT4 source from amd64 parser drops .zero directives from constant pools, causing VMOVDQA SIGSEGV #80