Implement missing FilterBuilder functions

[zoedsoupe]

Problem

The original implementation of logical and filtering functions in the FilterBuilder module used names (and, or, in, not) that conflicted with Elixir’s reserved keywords. Additionally, the existing functions lacked support for a more user-friendly DSL to represent conditions, making the API less intuitive and prone to errors when constructing complex queries with PostgREST.

Solution

• Renamed Functions:
• and/2 to all_of/2
• or/2 to any_of/2
• in/2 to within/2
• not/3 to negate/3

These changes avoid conflicts with Elixir’s reserved keywords while keeping the naming clear and aligned with their functionality.

• Implemented a Custom DSL:
• Introduced a simpler, declarative syntax for representing conditions to be used with all_of, any_of, and other logical filtering functions.
• Support for nested conditions (e.g., {:or, [...]}, {:and, [...]}).
• Added support for any and all modifiers in conditions (e.g., tags=like(any).{elixir,phoenix}).
• Refactored process_condition/1:
• Improved readability and modularity by splitting complex logic into helper functions.
• Added validation for supported operators to ensure safety and robustness.

Rationale

The renaming of functions resolves naming conflicts with Elixir’s core Kernel functions, improving the library’s compatibility and usability in pipelines.

The custom DSL aligns with Elixir’s declarative and functional programming principles, making it easier to construct and manage complex query conditions. This approach reduces the risk of errors caused by manually crafting PostgREST-compatible syntax strings and ensures consistency across the API.

This PR also addresses issue #8 by providing a more intuitive and extensible API for constructing filters and logical operations.