Update Sobol GSA to use sensobol package and validate ensemble design handling

[dlebauer]

(note: please sync target branch divine7022:develop with pecanproject/develop before review)

Description

This PR replaces the existing Sobol workflow with a sensobol-based implementation and hardens the ensemble design path used to run global sensitivity analyses.

Implementation was generated with ChatGPT based on my specifications and review.

Key changes:

• generate explicit Sobol A, B, and AB designs with sensobol
• preserve parent-child alignment in joint ensemble designs
• validate sampled input IDs and input_design indices
• compute Sobol indices from standardized ensemble.output.*.Rdata
• add tests for design expansion, parent behavior, and postprocessing

Motivation and Context

The previous Sobol path relied on implicitly splitting a PEcAn design matrix and passing it to sensitivity::soboljansen(). This introduced implicit assumptions about design structure, run counts, and factor alignment.

This PR makes the Sobol design explicit, aligns run counts with workflow execution, and standardizes postprocessing on PEcAn outputs.

Only the design construction and workflow integration are updated; no change to the original analysis intent (type-level Sobol sensitivity analysis)

Design Notes

• The issue was not with sensitivity::soboljansen() itself, but with how PEcAn constructed and adapted its design.
• The previous implementation split a single PEcAn design matrix into X1 and X2, assuming this produced a valid Sobol base design. This assumption was implicit and not validated.
• Sobol methods require a base sample size N and total runs N * (k + 2); this relationship was ambiguous in the previous workflow.
• sensobol maps directly to PEcAn’s workflow: explicit Sobol design → PEcAn runs → standardized outputs → Sobol indices.

Review Time Estimate

• Immediately
• Within one week
• When possible

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation.
• My name is in the list of CITATION.cff
• I agree that PEcAn Project may distribute my contribution under any or all of
  • the same license as the existing code,
  • and/or the BSD 3-clause license.
• I have updated the CHANGELOG.md.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.