Consider not transforming member access to EF.Property in query pipeline

We have EF.Property() as a user-facing mechanism for referencing shadow properties, which don't have a .NET property associated with them. At some point, we started also transforming regular MemberExpressions - where a .NET property **does** exist - into EF.Property nodes, as a sort of "universal representation" of property access within the query pipeline.

* EF.Property isn't client-evaluatable, so if a transformed EF.Property node ends up in client-evaluated code, the query fails. This is what happened in [#36761](https://github.com/dotnet/efcore/issues/36761).
* EF.Property obfuscates the expression trees we show to users in exception messages. That is, the user wrote simple .NET code with property access, but they're presented with an odd EF.Property MethodCallExpression node instead.
* EF.Property isn't universally used: in some cases we transform, in others we don't. So the value here is limited.
* Such transformations are inherently problematic with NativeAOT/trimming, since we need to do MakeGenericType to create the node (though this problem exists in many other areas).

Start by tracing the query pipeline transformations that convert regular MemberExpressions into EF.Property nodes. Compare those paths with user-facing shadow-property access, client evaluation, exception expression output, and the MakeGenericType concern. Done requires a decided transformation policy and validation that the reported failure modes are addressed.

Written by the indexing model from the issue text.