opt: high number of filters combined with dualing indexes can pick bad plan

From support ticket [#2172](https://github.com/cockroachlabs/support/issues/2172)

This ticket has 15 filters that throws off the statistics and makes us make bad planning choices. Should we place a limit on those?

Basically what happens is the row estimate for the input to the lookup join is in the weeds (1e-5). This means that the cost of the lookup join will be small. Then there is a seesaw between the good index (primary key) where the two on conditions
make a table key and a bad index where only one of the on conditions is a table key. The first condition is an enum with 3 distinct values so using the bad index is a terrible idea because the enum isn't selective at all. However the primary table has 30 columns and the secondary index only has 5 so the that that the primary index has lookColsAreTableKey favors it but the difference in number of columns goes the other way.

Mucking with how we generate the selectivity of the filters can push things back towards the primary key but the main problem is we don't factor in the lookColsAreTableKey thing enough. At runtime we lookup one row in index per input key if we use the primary index but have to pick our way through 75k rows in the secondary index case which makes the query slow.

Jira issue: CRDB-26470