Fix bitmap AND/OR scans on the inside of a nestloop partition-wise join.

 Fix bitmap AND/OR scans on the inside of a nestloop partition-wise join.
 
 reparameterize_path_by_child() failed to reparameterize BitmapAnd
 and BitmapOr paths.  This matters only if such a path is chosen as
 the inside of a nestloop partition-wise join, where we have to pass
 in parameters from the outside of the nestloop.  If that did happen,
 we generated a bad plan that would likely lead to crashes at execution.
 
 This is not entirely reparameterize_path_by_child()'s fault though;
 it's the victim of an ancient decision (my ancient decision, I think)
 to not bother filling in param_info in BitmapAnd/Or path nodes.  That
 caused the function to believe that such nodes and their children
 contain no parameter references and so need not be processed.
 
 In hindsight that decision looks pretty penny-wise and pound-foolish:
 while it saves a few cycles during path node setup, we do commonly
 need the information later.  In particular, by reversing the decision
 and requiring valid param_info data in all nodes of a bitmap path
 tree, we can get rid of indxpath.c's get_bitmap_tree_required_outer()
 function, which computed the data on-demand.  It's not unlikely that
 that nets out as a savings of cycles in many scenarios.  A couple
 of other things in indxpath.c can be simplified as well.
 
 While here, get rid of some cases in reparameterize_path_by_child()
 that are visibly dead or useless, given that we only care about
 reparameterizing paths that can be on the inside of a parameterized
 nestloop.  This case reminds one of the maxim that untested code
 probably does not work, so I'm unwilling to leave unreachable code
 in this function.  (I did leave the T_Gather case in place even
 though it's not reached in the regression tests.  It's not very
 clear to me when the planner might prefer to put Gather below
 rather than above a nestloop, but at least in principle the case
 might be interesting.)
 
 Per bug #16536, originally from Arne Roland but with a test case
 by Andrew Gierth.  Back-patch to v11 where this code came in.
 
 Discussion: https://postgr.es/m/16536-2213ee0b3aad41fd@postgresql.org