feat: Add bigframes.execution_history API to track BigQuery jobs

[shuoweil]

This PR promotes execution_history() to the top-level bigframes namespace and upgrades it to track rich metadata for every BigQuery job executed during your session.

Key User Benefits:

• Easier Access: Call bigframes.execution_history() directly instead of digging into sub-namespaces.

• Rich Metadata Tracking: Captures structured statistics for both Query Jobs and Load Jobs including:
  - job_id and a direct Google Cloud Console URL for easy debugging.
  - Performance metrics: total_bytes_processed, duration_seconds, and slot_millis.
  - Query details (truncated preview of the SQL ran).

• Clean, Focused Logs: Automatically filters out internal library overhead (like schema validations and index uniqueness checks) so your history only shows the data processing steps you actually care about.

Usage Example:

    1 import bigframes.pandas as bpd
    2 import pandas as pd
    3 import bigframes
    4
    5 # ... run some bigframes operations ...
    6 df = bpd.read_gbq("SELECT 1")
    7
    8 # Upload some local data (triggers a Load Job)
    9 bpd.read_pandas(pd.DataFrame({'a': [1, 2, 3]}))
   10
   11 # Get a DataFrame of all BQ jobs run in this session
   12 history = bigframes.execution_history()
   13
   14 # Inspect recent queries, their costs, and durations
   15 print(history[['job_id', 'job_type', 'total_bytes_processed', 'duration_seconds', 'query']])

verified at:

1. vs code notebook: screen/8u2yhaRV9iHbDbF
2. colab notebook: screen/9L8VrP5y9DXhnZz

More testcases and notebook update will be checked in using separate PRs for easier review.

Fixes #<481840739> 🦕

[gemini-code-assist]

Code Review

This pull request implements an execution history feature to track and display BigQuery and local Polars jobs initiated during a session. Key changes include the addition of a JobMetadata dataclass, updates to ExecutionMetrics for job tracking, and a specialized _ExecutionHistory DataFrame for formatted output. Review feedback identifies opportunities to improve error logging in the HTML representation, remove redundant attribute assignments in the metrics logic, and ensure that bytes processed during local executions are consistently aggregated into session-level metrics.

[sycai]

Would we be able to pin down the lines that are susceptible to exceptions?

If yes, let's reduce the size of this try block by keeping only the code that is likely to throw exceptions.

[shuoweil]

Done! I've reduced the size of the try block in repr_html by moving the imports and self.empty check outside. Now it only wraps the code that might throw exceptions during data formatting and rendering.

[TrevorBergeron]

Why do we need execution history to be a dataframe itself? this comes with a lot of baggage

[shuoweil]

Great point! I've refactored _ExecutionHistory to use composition instead of inheritance. It is now a standard class that wraps a DataFrame internally, avoiding the baggage of subclassing. Users can call .to_dataframe() on it to get the DataFrame representation.

[TrevorBergeron]

How will this generalize to other execution tasks beyond specifically bq jobs?

[shuoweil]

I've added job_type to the HTML display to make it clearer when a job is Polars vs BigQuery. I also made the column selection safe against missing columns, so it can adapt to different execution engines that might provide different sets of metadata.