[1pt] PR: Fix eval_plots for env file and misc cleanup

[RobHanna-NOAA]

Opportunistically updating eval_plots when running it as part of fim_performance production output, and not part of the synthesize_test_case usage of eval_plots. See closes 1202.

Misc cleanup

• get rid of a gdal warning
• Removing some old invalid or unused files (confirmed with team)

Changes

• tools
  • eval_plots.py: Changed to look for explicit config env file via arg
  • pixel_counter.py: Added a line that stops a gdal warning of:

Removals

• src
  • aggregate_fim_outputs.py
  • finalize_srcs.py
  • reset_mannings.py
• tools
  • adjust_rc_with_feedback_py
• .github\PULL_REQUEST_TEMPLATE.MD: Updates. This PR reflects those changes, mostly to DevOps questions.

---

Testing

Generally, you do not copy this part into the ChangeLog). These are some quick notes on what you did test or what the reviewer to know for their tests.

• Ran eval_plots to get the FIM Performance files that are required for the FIM 6 production release. Outputs already validated, no more testing required.
• Ran eval_plots against the metrics file in EFS / ouputs/hand_4_8_6_1_orig and it was fine.

---

Deployment Plan (For developer use)

• Does the change impact inputs, docker or python packages?
  • Yes
  • No
• Has new or updated python packages or Dockerfile changes?
  • Yes
• Require new or adjusted data inputs? Does it have a way to version (folder or file dates?)
  • Yes
• If new or updated data sets, has the FIM code been updated and tested with the new/adjusted data (subset is fine, but must be a subset of the new data)?
  • Yes
• Require new pre-clip set?
  • Yes
• If applicable, has a deployment plan be created with the DevOps team? including what was run already, what needs to be copied to all 4/5 enviros, from where, what still needs to be run at scale, etc. Any notes are helpful.
  • Yes
  • I will shortly. :)

Notes to DevOps Team:

---

Issuer Checklist (For developer use)

You may update this checklist before and/or after creating the PR. If you're unsure about any of them, please ask, we're here to help! These items are what we are going to look for before merging your code.

• Informative and human-readable title, using the format: [_pt] PR: <description>
• Links are provided if this PR resolves an issue, or depends on another other PR
• If submitting a PR to the dev branch (the default branch), you have a descriptive Feature Branch name using the format: dev-<description-of-change> (e.g. dev-revise-levee-masking)
• Changes are limited to a single goal (no scope creep)
• The feature branch you're submitting as a PR is up to date (merged) with the latest dev branch
• pre-commit hooks were run locally
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future todos are captured in comments
• CHANGELOG updated with template version number, e.g. 4.x.x.x
• Add yourself as an assignee in the PR as well as the FIM Technical Lead

---

Merge Checklist (For Technical Lead use only)

• Update CHANGELOG with latest version number and merge date
• Update the Citation.cff file to reflect the latest version number in the CHANGELOG
• If applicable, update README with major alterations