feat(bigquery-jdbc): support picosecond in PreparedStatement parameters and batching - #14373

b/545231211

This PR adds picosecond timestamp support for PreparedStatement parameters and batch execution (EnableTimestampPicos=1), refactors statement pre-flight validation, and optimizes temporal string parsing.

Changes

• BigQueryParameterHandler: Supported enableTimestampPicos to preserve up to 12 fractional digits without premature microsecond truncation, cleaned up constructors into a final-field telescoping chain, and deleted the unused 2-arg formatValueForQueryParameter overload.
• BigQueryPreparedStatement: Propagated isEnableTimestampPicos across statement initialization and batch parameter handling (getStandardBatchJobConfiguration).
• BigQueryStatement: Converted getJobConfig into a pure configuration builder and extracted statement checks into validateExecution().
• BigQueryTemporalUtility: Consolidated fractional seconds truncation into a single helper (truncateFractionalSeconds) across all temporal parsers.
• Unit Tests: Added coverage for high-precision parameter binding and batching, while deduplicating helper tests and removing dead mock stubs.

Key Architectural Decisions

1. Legacy SQL Exception & Pre-Flight Validation (BigQueryStatement)

• Fail-Fast over Silent Data Loss: Legacy SQL cannot represent 12-digit picoseconds. Silently falling back to Legacy SQL would drop 6 decimal places of precision without warning. To prevent silent data corruption and maintain parity with the Simba driver, we fail execution explicitly.
• Pre-Flight Placement: This check previously lived inside getJobConfig. A configuration builder should not enforce fatal query-blocking logic. Moving it to validateExecution() alongside checkClosed() ensures we fail fast at statement execution entry—avoiding false "Executing query..." logs and unnecessary OpenTelemetry trace spans.
• Exception Classification: We intentionally use BigQueryJdbcException (general SQLException) instead of SQLSyntaxErrorException. The query itself (e.g., SELECT 1) is syntactically valid; the failure is a driver/session configuration conflict, not a SQL grammar defect.

2. ASCII Character Scanning Optimization (BigQueryTemporalUtility)

• In truncateFractionalSeconds, we replaced Character.isDigit(c) with a direct ASCII check (c >= '0' && c <= '9') and cached str.length().
• Because ISO-8601 and JDBC timestamp literals are strictly ASCII, avoiding Character.isDigit eliminates repeated Unicode table lookups and branching in the fractional scanning loop, reducing CPU overhead on hot result-set parsing paths.