Improve input validation and testing

[forsyth2]

Issue resolution

• Closes #625, #358

Select one: This pull request is...

• [ ] a bug fix: increment the patch version
• [x] a small improvement: increment the minor version
• [ ] an incompatible (non-backwards compatible) API change: increment the major version

1. Does this do what we want it to do?

Objectives: Adding "defensive programming" techniques to catch bad input early.

Functional code:

• Added guess_path_parameters & guess_section_parameters parameters, defaulting to True, to keep backwards compatibility. Setting to False allows for more transparency of what paths are being used.
• Added required parameter checks for certain diags sets, based on default.ini notes. Also added climo_diurnal_frequency check.
• Added dependencies to .settings files
• Added fail_on_dependency_skip parameter, defaulting to False, to keep backwards compatibility. Setting to True stops zppy if any job launch fails.
• Refactored code to be more modular. This is a great improvement to both readability & testing. Previously, much of zppy had been written in monolithic functions that made testing outside of full integration testing difficult. Now, real unit testing (as in, independent of the outside world) is more feasible.
• Added exit to tc_analysis if the cyclone_stitch dat file is empty.

Testing:

• Run all e3sm_diags sets on v2 and v3 comprehensive runs
• Changed reference years for e3sm_diags in v2 to start at 1870
• Added daily ts subtask to support the tropical_subseasonal e3sm_diags set.
• Remove simple_image_name so that all image check failures actually show up in the web's diff directory. Resolves #358.
• Added unit tests for the newly modular code.
• Updated expected results for integration tests.

Required:

• [x] Product Management: I have confirmed with the stakeholders that the objectives above are correct and complete.
  • As zppy's lead developer, I am the stakeholder these objectives are most relevant for.
• [x] Testing: I have added or modified at least one "min-case" configuration file to test this change. Every objective above is represented in at least one cfg.
  • These are not necessary since the purpose of this PR is to fix the comprehensive Weekly integration testing & add more unit tests.
• [x] Testing: I have considered likely and/or severe edge cases and have included them in testing.
  • I have attempted exhaustive unit testing of functions that don't interact with the outside world (i.e., functions that wouldn't need to be wrapped in the IO monad were the code written in Haskell).

If applicable:

• [x] Testing: this pull request introduces an important feature or bug fix that we must test often. I have updated the weekly-test configuration files, not just a "min-case" one.
• [x] Testing: this pull request adds at least one new possible parameter to the cfg. I have tested using this parameter with and without any other parameter that may interact with it.
  • fail_on_dependency_skip (False on v2,v3 tests; True on bundles tests) , guess_path_parameters, guess_section_parameters (False on v3 tests; True on v2, bundles tests)

2. Are the implementation details accurate & efficient?

Required:

• [x] Logic: I have visually inspected the entire pull request myself.
• [ ] Logic: I have left GitHub comments highlighting important pieces of code logic. I have had these code blocks reviewed by at least one other team member.

If applicable:

• [ ] Dependencies: This pull request introduces a new dependency. I have discussed this requirement with at least one other team member. The dependency is noted in zppy/conda, not just an import statement.
  • No new dependencies

3. Is this well documented?

Required:

• [x] Documentation: by looking at the docs, a new user could easily understand the functionality introduced by this pull request.
  • The bulk of zppy documentation is through reading parameter comments on default.ini.
  • This PR mainly affects developers, not users.

4. Is this code clean?

Required:

• [x] Readability: The code is as simple as possible and well-commented, such that a new team member could understand what's happening.
• [x] Pre-commit checks: All the pre-commits checks have passed.

If applicable:

• [ ] Software architecture: I have discussed relevant trade-offs in design decisions with at least one other team member. It is unlikely that this pull request will increase tech debt.