After the planner was fixed to convert some IN/EXISTS subqueries into
semijoins or antijoins, we had to prevent it from doing that in some
cases where the plans risked getting much worse.  The reason the plans
got worse was that in the unoptimized implementation, subqueries could
reference parameters from the outer query at any join level, and so
full table scans could be avoided even if they were one or more levels
of join below where the semi/anti join would be.  Now that we have
sufficient mechanism in the planner to handle such cases properly,
it should no longer be necessary to play dumb here.

This reverts commits 07b9936a and
cd1f0d04.  The latter was a stopgap
fix that wasn't really sufficiently analyzed at the time.  Rather
than just restricting ourselves to cases where the new join can be
stacked on the right-hand input, we should also consider whether it
can be stacked on the left-hand input.