Fix(bigquery)!: map native SHA512 to SHA2Digest, mirroring SHA256 [CLAUDE]

[Pawansingh3889]

Follow-up agreed in #7824: the bigquery parser mapped SHA256 to exp.SHA2Digest but SHA512 to exp.SHA2, while BigQuery returns BYTES for both.

Changes:

• The bigquery parser now maps native SHA512 to exp.SHA2Digest, mirroring the SHA256 line above it.
• Presto/Trino render exp.SHA2Digest through a dialect-specific function that encodes text-typed arguments (SHA512(TO_UTF8(x))), since the native digests take VARBINARY. Same convention as sha2_sql after the Fix(presto)!: preserve SHA256/SHA512 digest semantics, render SHA2 as hex string [CLAUDE] #7824 review: is_type only, type inference is assumed to have run separately. Unsupported lengths raise the usual warning.
• Clickhouse already wires exp.SHA2Digest on main, so BYTES semantics survive there with no change.

Test updates in test_bigquery.py:

• The annotated-types test now expects SELECT SHA512(TO_UTF8('foo')) on presto: BigQuery's SHA512 returns BYTES, so digest-to-digest is the value-preserving translation rather than the hex-string form.
• The SHA512 write block's presto/trino entries move to SHA512(x) for the same reason; spark2/clickhouse/bigquery entries are unchanged.

DuckDB renders 512-bit digests as UNHEX(SHA256(x)) behind the existing "only supports SHA256" unsupported-warning; that fallback predates this change and is left as is.

Full dialect suite: 742 passed, 11174 subtests.