Keep using *.nc.var in web and API

[infotroph]

Continuing from #3611, which turned creation of *.nc.var off by default, by re-enabling it for the web workflow and API. These are the only known places that rely on these files.

Description

• Web runs now set settings$nc_varfile_mode to "paired" at settings generation time, prompting workflow.R to call nc_write_varfiles. Output will remain identical to the existing default.
• Calls to the getWorkflows API endpoint will still read *.nc.var if they exist (for compatibility with existing runs), but will also write one combined nc_vars.txt for the whole outdir and use that for any *.nc that does not have a paired *.nc.var
• No changes made to sda.rewind.R; it will probably now warn cannot remove file '/your/outdir/1999.nc.var', reason 'No such file or directory', but this should not stop execution.

Motivation and Context

@mdietze in #3611 :

What if we add this to web/workflow.R and also add a new settings flag to control it? Set off by default but have the php turn it on?

Note also that, in addition to the web portal, sda.rewind.R and the api's runs.R both look for nc.var files. The former is one of Raiho's helper functions for cleaning up -- I don't think anyone is using it and I don't think that not finding the files will break anything. The latter would be a breaking change, so we should make sure that API-based model runs also turn on the the nc.var changes by default as well. AFAIK both the web and API based runs are currently low volume so generating these files by default in that context should be fine.

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.

[dlebauer]

Looks good

Updates to CHANGELOG to reference this and #3611?

[infotroph]

Updates to CHANGELOG to reference this and #3611?

Done in 09737ff along with some changelog cleanup -- seems we've been lax about making sure new changes get added to the unreleased section rather than mixed into previously tagged sections.