Components: Improve prop / update idiom consistency

[braughtg]

Currently components are handling props in different ways (e.g. with v-bind + watch or v-model). it would be better to have a consistent idiom for the way(s) that components handle props. This issue outlines a proposal for discussion and eventual implementation:

A component will include a prop for:

• required - if it can be required.
• showValidityStyling - if it accepts input and can be invalid.
• other information that the component needs (e.g. label, options, etc).
• every value collected by the component.

A prop that is not changed by the component (required, showValidityStyling, label, options, etc) will be used directly in the template (e.g. v-bind or {{ }}. There is no need to store them in a local data value or watch them.

For a prop representing a value collected by the component:

• The prop will be assigned to a data value in the component's data object.
• There will be a watch for the prop that updates the data value when the prop changes.
• The data value will be used in the template (e.g. v-bind or {{ }})
• The component in the template used to collect the value will have a v-on for the event that indicates a change in the value that calls an event handler function in the components methods.
• The event handler will update the data value and emit an update:prop event for the prop (e.g. update:location). The update: event will be suffixed with the prop name. Note: In this refactoring the prop names and/or update events should not be changed so that no other code will be affected. Issue #168 will address prop and update event names.

Note: This structure means avoiding the v-model shortcut for updating a data value without a v-on when its component changes. The reason for doing that is that we need to emit the update event anyway, so we still need the v-on and by doing the update manually it is more explicit and consistent across all values making the code easier to understand.

When the idiom is finalized,

• All components should be refactored to follow the idiom. This should not change their behavior at all, so any changes can be tested by running the current component tests for the component.
• The components/README.md file should be updated to reflect the idiom.

The components that should be evaluated and refactored are:

• [ ] - BedPicker
• [ ] - CommentBox
• [ ] - CropSelector
• [ ] - DateSelector
• [ ] - EquipmentSelector
• [ ] - LocationSelector
• [ ] - NumericInput
• [ ] - PickerBase
• [ ] - SelectorBase
• [ ] - SoilDisturbance
• [ ] - SubmitResetButtons
• [ ] - TextDisplay
• [ ] - TraySizeSelector

[braughtg]

Seems like there is a difference between a base component that is using the BootstrapVueNext components and one that is using the FarmData2 components.

I think it may be necessary to have two distinct idioms. One for when using a FarmData2 component as a sub-component and one when using a BootStrapVueNext component as a sub-component.