CSHARP-4684: Make part of IMongoQueryProvider public.

[rstam]

This PR is to solve an issue Damien was having getting the LoggedStages in the EF Core Provider in some cases.

Our earlier work made LoggedStage available via the IMongoQueryable interface. But when executing "scalar" (single valued) LINQ queries the EF Core Provider calls Execute directly on the internal IMongoQueryProvider.

Damien was having to use reflection to call the LoggedStages property on the IMongoQueryProvider.

This PR is a proposal to make part of the IMongoQueryProvider interface public by splitting the interface into public and internal parts.

I also made the ExecuteAsync method public. Damien, you are already calling the Execute method (defined in IQueryProvider), do you not need to call ExecuteAsync to handle async queries? Or does EF Core not support async queries?

For purposes of looking at this together I just used the existing CSHARP-4684 ticket. We may choose to create a new ticket.

[JamesKovacs]

LGTM. This feels like a good solution to avoid reflection in our EF provider. Splitting IMongoQueryProvider into public and internal parts is a good design choice.

[damieng]

Right now I only use Execute but want to support ExecuteAsync soon.

[damieng]

Tested this branch with the EF provider and it's working nicely without reflection. I switched to using Provider.LoggedStages for both single/scalar and enumerable so keep the code simpler my end - we could I guess remove it entirely though that would be a breaking change if anyone else has adopted it yet.

[damieng]

Looks great, nice to see cleaner tests as a result too.