feat(bindings): spans(<set_type>) — list of unit spans from a set

[estebanzimanyi]

Summary

Adds the set-level spans scalar for all five set types (intset/bigintset/floatset/dateset/tstzset), mirroring SpansetFunctions::Spanset_spans but reading a Set and calling the MEOS-side set_spans(s) + set_num_values(s) pair.

SpanFunctions::Set_spans already existed as a stub in src/temporal/span_functions.cpp but was never registered and had the wrong semantics — it was a BinaryExecutor calling set_to_span that returned a single Span, not a list. Replaced with a proper list-building implementation and registered spans(<set_type>) as a LIST(<span_type>) returner for each of the five set types.

Parity file

Unwraps the spans(intset ...) skip block — 1 query now active.

Test plan

• TZ=UTC ./build/release/test/unittest "<proj>/test/*" locally: 747 assertions pass across 13 test cases, no regressions.
• CI validates on linux_amd64, linux_arm64, macos, wasm.

Dependencies

Stacked on top of the MEOS error handler / lowercase aliases chain. Merge order: #7 → #8 → this.

🤖 Generated with Claude Code

[estebanzimanyi]

@nhungoc1508 — flagging a merge-target issue. This PR is marked MERGED, but the merge commit went into the stack-base branch, not main:

• feat(bindings): splitNspans / splitEachNspans lowercase aliases #8 was merged into fix/meos-error-handler (PR fix: install MEOS error handler so errors throw instead of exit() #7's branch — which itself was already merged into main, so the merge created a commit on a now-orphan branch)
• feat(bindings): spans(<set_type>) — list of unit spans from a set #9 was merged into feat/splitnspans-lowercase-alias (PR feat(bindings): splitNspans / splitEachNspans lowercase aliases #8's branch, same situation)

Net effect: this PR's contents never reached main. Verified by greping src/ on origin/main — splitnspans (lowercase) and spans(<set_type>) constructor are absent.

Re-landed in #44, which brings both commits forward as a clean linear history on top of main using the existing branch.

For future stacked PRs: when a base PR (e.g. #7) is merged into main, the dependent PRs (#8, #9) should have their base updated to main (gh pr edit <N> --base main) before merging — otherwise the merge target stays the now-deleted/abandoned base branch and the work doesn't propagate.