feat(tesseract): Initial BigQuery support

[waralexrom]

Check List

• Tests have been run in packages where changes made if available
• Linter has been run for changed code
• Tests for the changes have been added if not covered yet
• Docs have been added / updated if required

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.10%. Comparing base (91c5e87) to head (8337ea2).
Report is 15 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #9577   +/-   ##
=======================================
  Coverage   84.10%   84.10%           
=======================================
  Files         230      230           
  Lines       84409    84409           
=======================================
  Hits        70995    70995           
  Misses      13414    13414           

Flag	Coverage Δ
cubesql	84.10% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[KSDaemon]

Looks good! Left a few minor questions and suggestions.

[KSDaemon]

It would be much nicer to define it in backtick multiline.

[waralexrom]

That’s a debatable suggestion. Manual line concatenation helps keep both the Jinja logic and the rendered result readable.

'{% for time_item in seria  %}' +
    '    select \'{{ time_item[0] }}\' f, \'{{ time_item[1] }}\' t \n' +
'{% if not loop.last %} UNION ALL\n{% endif %}' +
'{% endfor %}' +

Converting it to a backtick multiline would cause an extra newline to be inserted before every select in the output.

And if I were to collapse the for and select into the same line, the template would become much harder to read — and the rendered SQL would also lose formatting by placing all SELECTs on one line.