Fix column mapping and logical condition parsing in VisitBinary, refactor for modularity

[banczynski]

What kind of change does this PR introduce?

Bug fix and code refactoring

What is the current behavior?

The original implementation of "VisitBinary" in "WhereExpressionVisitor" has two main issues:

• Properties mapped to database column names via the "[Column]" attribute (e.g., a property mapped to "column_name") are incorrectly mapped to different names (e.g., "columnname"), causing errors like "column test.columnname does not exist". This occurs because the call to "Visit" on the left expression ("node.Left") interferes with the state of the visitor, affecting the column name mapping.
• Nested logical conditions in LINQ expressions (e.g., combining multiple "&&" or "||" operators) are incorrectly parsed, resulting in an invalid logic tree like "(and.(and.(...),...))", which causes errors like "PGRST100: failed to parse logic tree".

Additionally, the original code:

• Mixes multiple responsibilities (e.g., processing logical operations, extracting column names, evaluating expressions) in a single method, making it harder to read and maintain.
• Duplicates logic for evaluating different types of expressions ("MemberExpression", "NewExpression", "UnaryExpression") across multiple helper methods ("HandleConstantExpression", "HandleMemberExpression", "HandleNewExpression", "HandleUnaryExpression").

What is the new behavior?

This PR fixes the column mapping and logical condition parsing issues, and refactors the code for better modularity and clarity compared to the original implementation:

• Fixed the column mapping issue by isolating column name extraction in a new method "ExtractColumnName" and avoiding calling "Visit" on the left expression, ensuring that "GetColumnFromMemberExpression" correctly maps properties to their column names as defined by the "[Column]" attribute, resolving errors like "column players.columnname does not exist".
• Fixed the parsing of nested logical conditions by introducing "FlattenLogicalConditions", which combines conditions at the same level into a single "and" or "or" filter (e.g., "and(column1.eq.value1,column2.gte.value2)"), resolving the "PGRST100" error for complex logical expressions.
• Fixed the column mapping issue by improving reflection in "GetColumnFromMemberExpression". Changed the method to use "GetCustomAttribute" and "GetCustomAttribute" for more robust attribute reflection, ensuring properties are correctly mapped to their database column names, addressing errors like "column test.PropertyName does not exist".
• Refactored "VisitBinary" to improve modularity and clarity:
  • Separated responsibilities into helper methods ("ExtractColumnName", "EvaluateRightExpression", "ProcessSubExpression"), making the code more organized and easier to maintain.
  • Unified the duplicated logic for evaluating expressions ("MemberExpression", "NewExpression", "UnaryExpression") into a single generic method "EvaluateExpression", reducing code duplication.
  • Maintained special handling for types like "DateTime", "DateTimeOffset", "Guid", and "Enum", centralizing the logic in "EvaluateRightExpression" instead of spreading it across multiple "Handle*" methods.

The new implementation ensures that queries with nested logical conditions (e.g., ".Where(p => p.Column1 == value1 && p.Column2 >= value2)") are correctly translated to valid PostgREST filters like "WHERE column1 = {value1} AND column2 >= {value2}", resolving the "PGRST100" and "column players.PropertyName does not exist" errors, while being more modular.

Additional context

The refactoring focuses on modularity to make the code easier to maintain and extend in the future, while also improving readability.