Make AbstractQueryFilterPlugin and QueryFilter plugins ModelFieldPlugin instead of ModelQueryPlugin

[MasonD]

Description

Conceptually and in practice, there's no difference between a ModelQuery and ModelField that impacts filtering. QueryFilter works as-is when applied as a plugin to a ModelField for a hasMany or manyMany relationship. (Or more esoterically a custom-resolved field on a DataObject that returns a DataList and has a resolvedModelClass set in the config. Or even more esoterically, a user-defined SchemaModelInterface which can create ModelFields of DataObjectModels. I've tested all these configurations.)

The only place where AbstractQueryFilterPlugin or QueryFilter make the assumption that the field it's applied to is a ModelQuery specifically is in QueryFilter's ::apply, where it asserts that the field is backed by a DataObject model incorrectly, relying on ModelQuery's (probably inconsistent?) behaviour of storing the query's return result as the ModelQuery's ->getModel(). ModelField's ->getModel() is actually the parent model, so I would change the assertion to use ->getModelType() instead.

Additional context or points of discussion

The only gotcha here is that the plugins use an input type named after the filtered type, meaning filters defined for all fields with the same type will merge their filter type's fields, meaning all fields can be filtered by any field listed in any of the plugin configs. This is already an issue when adding the filter plugin to both readOne and read queries. Should we consider allowing a custom filter type name defined in the plugin's config so the user can split the types if they want? The complication would be how to handle nested filter type names.

Validations

• You intend to implement the feature yourself
• You have read the contributing guide
• You strongly believe this feature should be in core, rather than being its own community module
• You have checked for existing issues or pull requests related to this feature (and didn't find any)