Changes what portion of the query plan appears in the rejectedPlans field. Previously, rejected plans could be extended with some aggregation logic - things like $group could show up. Now, only the `find` portion of the query appears.

This change ensures that executionStats for the rejectedPlans are non-zero. Inside the server, extending the plans with aggregations erases the previously collected execution stats. By avoiding this extension, customers can now see statistics such as how many documents or keys a rejected plan examined.

Deciding which plan is the winner does not use the aggregation logic anyway. So now the rejected plans correspond with what plans were run during runtime planning.

This means that the rejectedPlans do not hold the entire query. This was already the case prior to this change, as some aggregations cannot be pushed down to `find`.

Description of Linked Ticket

In SBE, if you run explain("allPlansExecution") on a query  that have extra pipeline stages pushed down (for example, $group), execution stats for rejected plans will be all zeros.

That is because we extend rejected plans with aggregation pipeline only in explain(), resetting execution stats.

https://github.com/mongodb/mongo/blob/83be8a3f59780501b7469e08b1cd2ac318f8ca86/src/mongo/db/query/sbe_multi_planner.cpp#L377

allPlansExecution is an important debug tool for SBE multi planner that we should fix.

For example, for allPlansExecution purposes, we don't have to extend the plans with an agg pipeline, because agg pipeline doesn't affect plan selection anyway. This is the way it is done in classic multiplanner for SBE.

Also, users on version 6.0 and 7.0 only use SBE when we have a $group or $lookup, so this is completely broken for them. We should fix and backport this.