fix(filter)!: ignore a fully prevented clause by its query name

[pdevito3]

Summary

• QueryKitPropertyMappings.ReplaceAliasesWithPropertyPaths no longer throws InvalidOperationException for the query name of a property with PreventFilter() and PreventSort(). It replaces the query name like any other query name.
• On v2, fix(filter)!: resolve query names in the grammar again #154 already deleted the call of this check from ParseFilter. A filter that uses the query name of a fully prevented property removes the clause (or replaces it with true == true), like any prevented property.

v1.14.2 behavior

With HasQueryName("name").PreventFilter().PreventSort() on Title:

Input	v1.14.2	This PR on v2
name == "x" || Age > 100	InvalidOperationException: 'Title' is not allowed for filtering or sorting.	x => (x.Age > 100)
Title == "name == x" (query name name on FirstName)	InvalidOperationException, because the regex matched text inside the quoted value	x => (x.Title == "name == x")
ReplaceAliasesWithPropertyPaths("name == \"x\"")	InvalidOperationException	Title == "x"

Justification

A prevented property must act the same way in every form: the clause is ignored by IgnoredClauseBehavior. The throw applied only when both settings were on, only in front of an operator, and also inside quoted values.

Migration

If a client caught InvalidOperationException for this case, it now gets the result of the other clauses.

Tests

• Unit PropertyResolverTests: query_name_of_a_property_prevented_for_filter_and_sort_in_a_quoted_value_is_not_changed and alias_replacement_does_not_throw_for_a_property_prevented_for_filter_and_sort.
• Integration (Postgres): prevented_property_clause_by_its_query_name_under_or_does_not_return_every_row.
• dotnet test: 529 unit tests and 325 Postgres integration tests pass.