CI: add meta-analysis notebook and modularize rendering workflow

[AritraDey-Dev]

Description

This PR adds the newly introduced meta-analysis notebook to the CI rendering workflow to ensure it compiles successfully after #3707.
Additionally, a new notebooks.yaml file has been introduced to improve maintainability.When new notebooks are added to the repo, only their paths need to be listed in notebooks.yaml, avoiding direct changes to the render-quarto.yaml gh action workflow.

Motivation and Context

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.

[infotroph]

• Nitpick: Can we rename this notebooks.yml instead of mixing "yaml" and "yml" extensions?
• More substantive: Am I right this is only used by reading it into workflows/render-quarto.yml? If so, why not define it directly in that file[*]? Feels confusing to have the list of notebooks live in a third place that's neither alongside the files nor alongside the code that uses them.

[*]possibly it could be specified as a matrix that could then be processed in parallel? I haven't looked carefully, so may be missing a reason that wouldn't work

[AritraDey-Dev]

If so, why not define it directly in that file[*]?

Yes, it is used by the render-quarto workflow, so it can definitely be kept in that file itself. will do that.

[AritraDey-Dev]

[*]possibly it could be specified as a matrix that could then be processed in parallel? I haven't looked carefully, so may be missing a reason that wouldn't work

I've considered this before.I am slightly against this, particularly for this workflow, since we only use parallel tasks when they are long-running. In this case, rendering demo 1 takes approximately 20 seconds, and the meta-analysis takes about the same time. The uncertainty notebook, however, takes longer which is around 150 seconds.
Considering these durations, if we run them in parallel, we first need to build the base image and then render the notebooks. For each parallel matrix job, additional time is spent pulling the image and setting up the job, which will defintely end up taking more total time than the actual rendering.
Also after rendering the notebooks, we have to merge the artifacts in order to commit the changes to the documentation repository, which again adds more overhead compared to what we are doing atm.So, do you think we should consider this approach?

[infotroph]

👍 No need to consider further! "setup and postprocessing make sense to do once and they take longer than rendering" is enough reason by itself to to not bother with parallel yet (or possibly ever).

[infotroph]

Will it stay true that we want this job to render and upload every Quarto notebook in the tutorials directory? If so I think you could remove this entire block and avoid needing to update this file in the future by using shell wildcards below: quarto render /work/documentation/tutorials/**/*.qmd --to html, for p in documentation/tutorials/**/*.qmd; do, etc.

[infotroph]

(Obviously this suggestion is completely incompatible with my retracted parallel rendering idea!)