Uses distribution in data to set up uncertainty

[kellijohnson-NOAA]

What is the feature?

• No longer passes the uncertainty to parameters. The distributional assumption now lives in the data.

How have you implemented the solution?

• A formula system was created for the "uncertainty" column of FIMSFrame@data. The column takes the form of "~(<central_tendency_label> = <derived_quantity>, <uncertainty_parameter_label> = <user_input>)". For example, "~lognormal(mean = log_landings_expected, sd = 0.001)" would be a viable entry for landings data.
• parse_data_distribution() parses this out into a list which is then used to set up the data distributions among other things

Does the PR impact any other area of the project, maybe another repo?

• I deleted quite a few tests so we will need to check coverage
• This PR and the parent branch are behind main by a commit and thus still failing R CMD check for linux.

---

Instructions for code reviewer

👋Hello reviewer👋, thank you for taking the time to review this PR!

• Please use this checklist during your review, checking off items that you have verified are complete but feel free to skip over items that are not relevant!
• See the GitHub documentation for how to comment on a PR to indicate where you have questions or changes are needed before approving the PR.
• Please use standard conventional messages for both commit messages and comments
• PR reviews are a great way to learn so feel free to share your tips and tricks. However, when suggesting changes to the PR that are optional please include nit: (for nitpicking) as the comment type. For example, nit: I prefer using a data.frame() instead of a matrix because ...
• Engage with the developer. Make it clear when the PR is approved by selecting the approved status, and potentially commenting on the PR with something like This PR is now ready to be merged.

Checklist

• The code is well-designed
• The code is designed well for both users and developers
• Code coverage remains high- [ ] Comments are clear, useful, and explain why instead of what
• Code is appropriately documented (doxygen and roxygen)

[Bai-Li-NOAA]

Do we need to add checks here to ensure sd_values are valid? R won't throw an error if .default = NA_real_. Do we need to check some potential edge cases as well, such as sd_value being 0 or negative?

[kellijohnson-NOAA]

Great suggestion @Bai-Li-NOAA . I added one to check that sdlog and sd are always positive values. Are there any other checks that you can think of?

[Bai-Li-NOAA]

I think I ended up leaving more non-blocking suggestions that could become follow-up issues. 😉 Let me know if you have any questions.

[kellijohnson-NOAA]

@Bai-Li-NOAA I did quite a bit of work to this branch since your review. I think that we should merge it into your branch as a single commit and then merge the whole thing into main. I am going to open a PR in r4ss/r4ss and NOAA-FIMS/case-studies to update both of the repos to use this new version and I would like to get approval of those two PRs before we merge this stuff into main. That way people are reviewing the user experience rather than the logic. What do you think?