feat(events)!: advancedFilter becomes a filter expression

[olavgg]

BREAKING CHANGE: EventFilterForm::set_advanced_filter takes a string instead of an AdvancedEventFilter, and the Filter, AdvancedEventFilter and RelatedResourceFilter types are gone. The api replaced the nested and/or/not JSON with a boolean expression it parses itself:

form.set_advanced_filter("type NOT LIKE 'pump' AND (subType = 'water'
                          OR subType = 'gas')");

The tree was worth less than it looked. Of the nine Filter variants, three -- Range, ContainsAny, ContainsAll -- had no server-side binding at all and returned a 500, and IsSet reached a code path that could not read the property it was given. Nothing outside src/filters.rs constructed one: Filter was never re-exported at the crate root, RelatedResourceFilter had no public constructor, and the Python bindings never exposed any of it. So the blast radius is small for something this loud.

The field name and its serde attributes are unchanged, so the wire key is still advancedFilter and an unset filter still omits it rather than sending null -- which matters, because the api rejects unknown and null-typed keys. advanced_filter_serializes_as_camel_case stays as the guard for that and now also pins the value shape.

Python gains the parameter in the same release rather than being left without advanced filtering: advanced_filter= on both filter() methods, through the shared event_filter_form builder, with the two stubs updated.

The expression is validated by the api, not here. An invalid one comes back as a 400 carrying an offset and, where the fix is unambiguous, the corrected expression -- so a client can underline the mistake or offer the repair without knowing the grammar.

Version 0.4.0: removing public types is breaking, and under Cargo's 0.x rules that is a minor bump. All three manifests move together, as the versions CI job requires.