Parallelize ClimaCore sparse matrix assembly + polygon intersections

[asinghvi17]

Adds a new interface for the intersection operator, so that ClimaCore only needs to define its intersection operator, not the full sparse matrix assembly.

Also adds some benchmarks for the ClimaCore regridder construction, as well as performance optimisation / improvements there.

[hgpeterson]

I've looked over the changes and verified that tests pass locally (including examples/low_level/climacore_exp.jl). Most of the PR goes over my head, but I get the general idea of parallelizing some of these operations. I question whether this added complexity in the code is really necessary, though. Running the benchmarks in bench on a single thread takes ~5 seconds for the slowest case while on 8 threads the slowest case is ~1.5 seconds. Are there any use cases where these computations need to occur more than once? From what I understand, we only need to do them once at the beginning of the simulation.

[hgpeterson]

BTW: I also ran a /code-review in claude and it had 10 comments. They were mostly small stuff from what I could tell, but happy to share them all if desired. The one it flagged as most important was:

---

src/regridder/intersection_areas.jl:161

Summary: _parallel_coo's threaded branch crashes with MethodError: reducing over an empty collection when items is empty, because ChunkSplitters.chunks([]; n=...) yields 0 partitions so all_results = [] and reduce(vcat, getindex.([], 1)) has no init.

Failure scenario: Verified live: ConservativeRegridding.intersection_areas(GO.Planar(), GOCore.True(), dst_tree, src_tree) for two non-overlapping grids throws this error, while False() correctly returns an empty sparse matrix. Since Regridder(dst, src) defaults to threaded = True(), any Regridder construction between grids/spaces with zero candidate pairs (disjoint domains, a regional patch, or — newly via this PR — an SE element set that doesn't overlap an FV grid) crashes instead of producing an empty/all-zero matrix. The old SE↔FV code built sparse(rows,cols,vals,...) directly and handled this fine regardless of threaded; this PR routes those constructors through the same vulnerable shared path for the first time.

---

Should be an easy fix, but would we ever call Regridder for a case with no overlaps?

[asinghvi17]

Hmm for that one it's certainly possible that one might try to construct a reusable regridder on two non-overlapping areas (though it would be a bit dumb). The fix should be simple enough that we can just do it there.

In general the reason for complexity is twofold:

1. Polygon intersection (and the other things required for spectral element) is the heaviest part of the workload, so parallelizing that is always nice. Especially for the large (e.g. two 3600x1800 grids) cases, this becomes quite essential to having a reasonable runtime, since those can take 200-500 seconds.
2. This allows the user to specify exactly what workflow they want to use, so e.g. for an intersection-grid for flux regridding, you can hook in to all the infrastructure and it just works, without having to reimplement the parallelism etc. Especially if you might want to collect extra information, having these hooks becomes very useful.

[hgpeterson]

Hi @asinghvi17, sorry for the late reply; was at a conference.

I can see how very high resolution setups would benefit from this change. If that's a high priority right now, then I'm okay with you merging this in as it doesn't seem to affect our current ClimaCoupler runs.

[asinghvi17]

will fix docs in a follow up PR