fix: filter values are not validated

[SychO9]

Fixes #3627

Changes proposed in this pull request:
This PR along with a tag v0.5.2 in SychO9/json-api-php@728047e fixes a lack of validation for query parameters that would lead to multiple server errors.

Reviewers should focus on:
I'm surprised we never noticed the lack of validation for filters, that said the interface forces a string type, whereas a filter can be an array, unfortunately, we can only change that in 2.0, but at least, implementations of the interface can do without the string type.

Necessity

• Has the problem that is being solved here been clearly explained?
• If applicable, have various options for solving this problem been considered?
• For core PRs, does this need to be in core, or could it be in an extension?
• Are we willing to maintain this for years / potentially forever?

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Backend changes: tests are green (run composer test).
• Core developer confirmed locally this works as intended.
• Tests have been added, or are not appropriate here.

Required changes:

• Related documentation PR: (Remove if irrelevant)
• Related core extension PRs: (Remove if irrelevant)

[askvortsov1]

Should these require string? / why not add type annotations?

[SychO9]

filterValue is either a string or an array, w can't use mixed and we can't use sting|array yet.

The second parameter does need to be typed though.

[askvortsov1]

Another question, sorry. If we're removing the string type annotation for $filterValue, would it be possible to specify a union type in the doc block so we still get some kind of typechecking?

[askvortsov1]

If this is an intArray, shouldn't it be whereIn?

[SychO9]

nice catch! technically I should have kept it an int rather than an array<int>. But nothing wrong with allowing filtering per many tags.

[SychO9]

Another question, sorry. If we're removing the string type annotation for $filterValue, would it be possible to specify a union type in the doc block so we still get some kind of typechecking?

We can't add a more open type than the code type string s that is incorrect so phpstan errors with it. Unless you meant doing so on every filter implementation, in wich case I don't think it would actually be useful since the interface is what's picked up when dynamically applying each individual filter.