Implement IQueryable instead of IOrderedQueryable in EntityQueryable, introduce OrderedEntityQueryable

[roji]

DbSet returns the internal EntityQueryable, which implements IOrderedQueryable even though DbSets aren't ordered; since EF's LINQ provider always returns EntityQueryable, this is required in order to allow casting EntityQueryable to IOrderedQueryable when the OrderBy operator is called (see the source code). However, it means that checks whether the IQueryable returned from DbSet is ordered will return true, although it isn't (see #34363).

Instead, our implementation of CreateQuery() could check the return type of the method for the node being created, and return a different type (OrderedEntityQueryable) when that method returns IOrderedQueryable. This would align the runtime type we return with the static typing of the operators being composed. It would also add a runtime reflection check for each LINQ operator composition.

Overall I'm not sure this is important. Although in a very technical sense we're incorrect, the main point of IOrderedQueryable is for static typing (i.e. not allow ThenBy without a previous OrderBy), not for runtime checking. The proof is that we've had only a single complaint about this in EF's history (#34363), and even that complaint is mistaken (there's an expectation for Select to flow orderability, which it does not).