move to a more package like functionalized workflow

[srearl]

We probably cannot break from the horribly inefficient, iterative scripting approach to processing these data owing to the nuanced errors and associated fixes unique to each data collection, but, once formatted appropriately, we most could certainly develop a more efficient workflow for the part of the workflow that loads the data into the database. See the micromet workflow as a good example where we can, for example, use insert returns to ensure expected outcomes. Also, even with the challenges, we could do a better job even with the data-processing side (e.g., see remove ambiguous helper). This may be especially true if the KoBo workflow and platform prove robust such that this could be our data-acquisition platform for the foreseeable future.

[srearl]

We made some progress toward this with the fall 2022 survey, notably functionalizing identifying and annotating (in the database) cases where a new stem measurement for a given plotplantdirection is not available. A more package-like workflow will be worth developing further if we opt to continue to use the KoBo framework.

[srearl]

Note that the spring 2024 data were not a good candidate for workflow development and better error checking as these data were perfect with zero errors detected (using the existing approaches).