Query: Re-evaluate concept of pending selector in nav expansion

[smitpatel]

When we rewrote query in 3.0, we added a concept called pending selector in nav expansion. Since nav expansion is expanding navigations, we defer applying the projection and keep intermediate shape to reuse the navigations already expanded. This is useful in many scenarios but deferring projection has side effects. See #7776 for one example. That is just one scenario. Any time FirstOrDefault is used in any way (selectmany or next select), by deferring that projection we duplicate the subquery for any property access on that. Not only it causes ugly query but potentially bad perf.

Instead of deferring the projection if we applied projection in above case then, during translation it would cause a subquery and any further property access would be columns coming out subquery. Hence it can be translated without causing client eval error at the same time avoid repeating subquery. This approach would do exactly what @maumar requested in the #7776 (comment)

Making this work will require

• Update navigation expansion to take a hybrid approach to apply projection at the same time remember the navigations already expanded to reuse them.
  • We only need to remember navigations which can be accessible by projection being applied.
• Update translation pipeline to handle translating query operators after client eval phase if it can be server evaluated.

There are few more associated issues this would fix. #18775

[smitpatel]

#21201 added code path to process joins when outer is client eval. Currently in the absence of this issue the code path is never hit. When fixing this, consider the code path and change or remove it is not needed.