Filter core log type lists by Crop/variety, Species/breed, Season, etc

Had a feature request today to add exposed filters to the Harvests and Inputs lists so that you can filter by "Crop/variety" and "Season".

This is tricky right now, because harvests and inputs are more general log types, which can be used on any type of asset (not just plantings). But the "season" and "crop/variety" fields are only on plantings. The farm_crop module (which adds plantings and those fields) depends on the farm_log_harvest and farm_log_input modules (which provide harvest and input log types, respectively), so technically the harvest and input modules aren't aware of the "crop/variety" and "season" fields. Adding those filters would create a circular dependency between farm_log_harvest/farm_log_input and farm_crop.

This request can be thought of more generally, to include "activity" and "observation" logs as well, which, along with "harvests", and "inputs", comprise the core log types that are available to all asset types in farmOS. So any solution to the original request should be able to accommodate all core log types.

There are a few ways to approach this...

Alter the Views

One way would be to implement hook_views_default_views_alter() inside the farm_crop module, and add the "Crop/variety" and "Season" filters to all the core log lists. This would be a quick and dirty way to do it. The drawbacks are:

1) The same would have to be done for Animals if we wanted to be able to filter by "Species/breed" in the same lists, and any other asset/field combinations, which could quickly add up to a lot of cluttered filters. It also would be kind of confusing to see "Species/breed" alongside "Crop/variety" in the same list of filters - without knowing that one is for Plantings and one is for Animals. And again, other modules provide more filters (ie: Mushrooms with Substrate type and Mushroom species).

2) When you try to re-export the Features modules, I think it would include the altered modifications, which means you would need to revert those changes before committing other changes. This would add overhead to the module maintenance moving forward, and there's always a chance that it would get accidentally committed.

Generalize the filters

The better approach (but more work involved) would be to generalize the filters so that they can be used across all asset types more easily.

For example, "Crop/variety" in Plantings is analogous to "Species/breed" in animals, and "Mushroom species" in mushrooms. Could they be merged together into a general "Species/breed/variety" vocabulary? I like that from a data organization standpoint, but it could also cause confusion if your terms are mixed into one vocabulary.

On the other hand "Season" could be pretty easily generalized to any asset. So let's just spin off another feature request to generalize that: #2934717: Generalize season vocabulary to all asset types