Refactoring status values

[jgaehring]

I refactored and tidied up a bit before getting back to the main alpha.1 milestone issues.

The main thing is how the status value was being converted from the backend string value (eg, "Green") to an emoji for the farm list (eg, "🟢"). I added a couple hacks and sloppy naming conventions in 9327343, and that was probably fine b/c we know we want to eventually use some kind of numeric code for the primary status value, possibly for #6, but it got me thinking more about the domain model.

I think there is a valid case to make that the color codes are in one sense "original" data, insofar as they can represent a verbal, qualitative assessment, but in another sense they are meant to display the status as a computed value, derived from the last known assessment value and the time that has elapsed since it was recorded, as laid out in #6.

To my mind, it makes sense to call the original qualitative assessment value a triage value, which can be stored as an integer,¹ while the term status is reserved for the computed or derived value at any given moment and can be a float or a string or whatever form makes sense in the given context. Both can be represented by the same color coding or other indicators in the UI, and it may also be helpful to store both in some capacity, but a status value can be treated as ephemeral state, whereas a triage value is original data that should be preserved. This distinction should become more apparent once we begin deriving the status from not just qualitative but quantitative assessments, as well as aggregations of both.

Footnotes

1. I haven't made up my mind at all about this, but possibly the set of [-1, 0, 1, 2], where 0 is red, 1 is yellow and 2 (or anything higher than 1) is green; -1 is for an inactive or ignored status, something we might represent with a neutral color. ↩