feat: property filter custom operator support

[revezard]

Description

Adds end-to-end support for custom operators in the Property Filter component. Consumers can define their own operator strings with custom matching logic, display descriptions, and accessible labels.

Key changes:

• getAllowedOperators now preserves custom operators (appended after known operators in standard display order)
• getAllowedFreeTextOperators updated to handle extended operator objects and preserve custom operators
• operatorToDescription checks custom description before built-in i18n, allowing consumers to override predefined operator labels (e.g. > described as "After" for date properties)
• matchOperator requires word boundary after text-based operators to prevent false matches (e.g. "in" not matching "internal")
• Token editor resolves custom operator descriptions from filtering properties when in free-text mode
• Added getOperatorDescription accessor to InternalFilteringProperty

Depends on: cloudscape-design/collection-hooks#151

Related links, issue #, if available: n/a

How has this been tested?

• Unit tests for operatorToDescription (custom description override, fallback to i18n, unknown operators)
• Unit tests for getAllowedOperators (custom operators preserved, ordering, duplicates)
• Unit tests for matchOperator (text-based operator word boundary, case-insensitive matching, symbolic operators unaffected)
• Unit tests for parseText (text-based operators with space, case-insensitive, no false match on value prefix)
• Integration test for autosuggest options (custom description in dropdown, override of predefined operator descriptions)
• Demo page at /#/light/property-filter/property-filter-custom-operator exercising all scenarios

Review checklist

The following items are to be evaluated by the author(s) and the reviewer(s).

Correctness

• Changes include appropriate documentation updates.
• Changes are backward-compatible if not indicated, see CONTRIBUTING.md.
• Changes do not include unsupported browser features, see CONTRIBUTING.md.
• Changes were manually tested for accessibility, see accessibility guidelines.

Security

• If the code handles URLs: all URLs are validated through the checkSafeUrl function.

Testing

• Changes are covered with new/existing unit tests?
• Changes are covered with new/existing integration tests?

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.