Inconsistent handling of `NOT IN` and `Not(In)` constructs

[huandu]

Per discussion in #190, there are some issues introduced by the PR.

1. Silent Drop of NOT IN:

• The current implementation silently drops NOT IN clauses (an always-true condition), which can corrupt query results.
• For example: In an OR clause where all other conditions are FALSE, dropping NOT IN forces the query to return FALSE instead of TRUE.
• Proposal: Replace NOT IN with an explicit always-true statement (e.g., 0 = 0) instead of removing it.

2. Inconsistency Between NotIn and Not(In):

• c.NotIn("$a") and c.Not(c.In("$a")) produce divergent SQL outputs. This violates expectations of uniform behavior for logically equivalent operations.
• Expected Behavior:
  • NOT IN should be preserved as an always-true condition (like IN is preserved as 1=0 for always-false).
  • c.NotIn() and c.Not(c.In()) should generate identical SQL.