Optimization: Enable SIP based on cardinality information without a filter

[ray6080]

Description

When we're trying to apply SIP from the build side to the probe side, or from the probe side to the build side, we only choose to apply SIP when there is filter on the build or probe side. This is to avoid worst cases that cardinality estimation can be very wrong. However, this also limits the use of SIP in scenarios where output distinct values is small and serve as "filters":

1. Num of distinct Dst nodes scanned from the rel table can be small. E.g., MATCH (a)-[e]->(b) RETURN b.id. For plan JOIN(SCAN(b))(Scan(a)Extend(e)), Scan(a)Extend(e) can be selective if e contains few distinct b nodes as dst.
2. Table function can output few distinct nodes. Vector index search can serve as an example as it usually outputs only top k tuples, which is usually much smaller compared to the base node table. Note that SIPDirection::FORCE_BUILD_TO_PROBE is now used in vector index search to force SIP, which should be refactored away along with addressing this issue.