Operation Cleanup

[knelson-farmbeltnorth]

In reviewing the Operation object, I've made a few minor changes. Logging here for visibility:

1. LoggedVariables should not be required. I updated the definition as follows: "The data variables on this Operation to be reported in any Summary Values and/or Spatial Records. Required in most cases. Exceptions would be if the data is simply reporting that a certain field was harvested as of a specific date or planted with a specific product, etc., without any further information available."
2. I moved Calibration Factors from the Operation to the individual Logged Variable. The Calibration Factor had a required LoggedVariableId so it made more sense as a property of the LoggedVariable.
3. I removed Id and Name from Calibration Factor. These appear to have carried over from the C# implementation and are not relevant when each factor is included by value.
4. I changed the value of the factor from an abstract numeric value with a value and UOM to a simple factor number with a default of 1, since a UOM is not appropriate.

@strhea Please advise of any concerns.

There are a couple additional items for discussion:

1. Should an Operation relate back to both a WorkItemOperation and a Prescription? This raises the question about whether Prescriptions should require a WorkItemOperation parent, perhaps simply being embedded by value within the WorkItemOperation.
2. Related to the above, does Load need to be referred to be reference, or can it also be embedded within the Operation? Is there an advantage for further expansion of Loads if it resides as a primary entity within Documents?

[knelson-farmbeltnorth]

Agreement in 6 September 2023 call that Calibration Factors and Sensor Latencies should be removed from the model for the same reason we don't manage implement widths and offsets--there is too much complexity in implementation and it is best and readily handled by the OEM.

Re the Prescription and Load discussion items, we will leave things as is.