BUG: Canonicalize long-double padding across storage paths

[SwayamInSync]

Closes #111

The shared helpers in quad_common.h now handle:

• Canonical quad_value initialization
• Raw and canonical loads
• SLEEF and long-double stores
• ABI-specific x87 padding initialization

The x86/x86-64 x87 hot path uses the known representation:

memset(dst, 0, sizeof(value));
memcpy(dst, &value, 10);

This initializes the entire slot and then copies the 10 meaningful x87 bytes.

Other extended-precision ABIs use a conservative representation-independent fallback. Long-double formats without padding retain a direct copy. SLEEF storage remains unchanged.

Performance

SLEEF is unaffected because it continues to use its existing 16-byte copy.

On this x86-64 host, the optimized x87 canonical store added approximately 3–8% to typical long-double arithmetic kernels. Output-heavy operations show a larger relative cost (modf about 40%, float64-to-Quad casting about 70%) because they perform very little computation beyond writing one or two results.

The canonicalization is limited to padded x87 long-double output storage; non-padded long-double formats use the direct-copy path.