Expose SessionContext.register_variable / deregister_variable for SQL @var support

該 issue 提到了 PySessionContext、一個 PyVarProvider Rust wrapper，以及一個面向 Python 的 ABC，但沒有提供檔案或測試。首先追蹤現有的 PySessionContext bindings，以及 upstream SessionContext 中 register_variable 和 deregister_variable 的簽名。當 Python 呼叫端能夠提供一個 VarProvider、註冊和解除註冊它，並且能夠安全地跨越 GIL 邊界接收回呼時，即表示完成。

Background

DataFusion's SessionContext exposes register_variable(var_type, provider) and deregister_variable(var_type) for plugging in a VarProvider that resolves SQL @var / @@var references at execution time. These were surfaced during a v54 upstream coverage audit but are not exposed in the Python bindings.

Upstream signature

pub fn register_variable(&self, var_type: VarType, provider: Arc<dyn VarProvider + Send + Sync>)
pub fn deregister_variable(&self, var_type: VarType) -> Option<Arc<dyn VarProvider + Send + Sync>>

VarProvider is a small trait with get_value(&self, name: Vec<String>) -> Result<ScalarValue> and get_type(&self, name: &[String]) -> Option<DataType>.

User value

Enables SQL like SELECT * FROM sales WHERE region = @current_region AND user_id = @user_id where the provider supplies per-query values. Useful for multi-tenant SaaS embedders, BI / notebook tools that want session-scoped parameters without f-string interpolation (no SQL injection risk), and tools porting MySQL / Postgres SQL that uses session variables.

Why deferred

Effort estimate is medium (~250-400 LOC): needs a PyVarProvider Rust wrapper that calls back into a user-supplied Python object across the GIL boundary, plus the register / deregister bindings on PySessionContext, plus a Python-facing ABC. No open user requests at the time of audit, so the work is currently speculative. Filed for tracking; revisit when a concrete user need surfaces or to complete the upstream surface area.