[FEA] Support Project AST and AST JIT in cached broadcast hash join build-side projections #16509

Is your feature request related to a problem? Please describe.

When spark.rapids.sql.join.hashTable.reuse is enabled, a broadcast hash join keeps an executor-wide hash table for its build side. If Projects sit between the broadcast and the join, the hash-build cache keeps the bound build-side projection so it can rebuild the hash table after it is spilled. A rebuild can run in any later task.

Project AST and AST JIT evaluators compile native state lazily and release it when the task that compiled it completes. If that task completes while another task rebuilds with the same evaluators, the release can overlap CompiledExpression.computeColumn or AstJitProgram.computeTable, which cuDF does not support. #15312 avoids this by binding the cached projection for regular GPU evaluation only; per-task build-side projections still use AST and AST JIT.

Describe the solution you'd like

Give each cached build or rebuild invocation its own evaluators with explicit ownership:

• Create fresh AST and AST JIT evaluators for each invocation, and reuse them across retries and tiers within that invocation.
• Close them when the invocation finishes instead of registering task-completion cleanup.
• Close the source CompiledExpressions once an AstJitProgram is built, since the program copies its inputs.
• Measure program construction cost per rebuild with a warm native kernel cache.

Describe alternatives you've considered

Reference counting in the evaluators would avoid the use-after-free, but ownership would still depend on whichever task compiled the state first.

Additional context

Tests should cover a task that completes while another task rebuilds the cached hash table after a spill, and retry within one build or rebuild invocation. GpuBloomFilterMightContain uses the same lazily created, task-scoped native state, so the same ownership model may apply to other expressions retained by executor-wide caches.