Allow converting an EF LINQ query into a Microsoft.Extensions.VectorData IVectorSearchable

Microsoft.Extensions.VectorData (MEVD) provides a set of abstractions for dealing with vector databases, while EF providers typically expose their own querying mechanisms for users to express vector search in LINQ queries. MEVD and EF are thus two disconnected .NET technologies for interacting with vector databases.

One of MEVD's value proposals is the ability to build high-level frameworks/components on top of vector search; for example, a RAG framework (similar to LlamaIndex) could leverage MEVD to talk to any vector database. Existing EF users could point MEVD at their EF-managed database, but this involves dealing with two data access layers and could cause various friction. Ideally, an existing EF users would be able to simply expose their EF-managed database directly as an MEVD implementation, rather than using e.g. the MEVD PostgreSQL provider to access a database that's already being used with the EF PostgreSQL provider.

Another motivation: MEVD providers are typically quite limited in the querying capabilities they implement; the MEVD PG provider doesn't came anywhere close to what EF supports in terms of SQL querying (and never will). Ideally users would be able to unlock the full querying power of their database (which is what EF does), while at the same time being able to use MEVD with higher-level components.

---

### Design/implementation thoughts

To implement this, we'd likely introduce a terminating LINQ operator that users compose on an EF LINQ query, and which returns an MEVD IVectorSearchable (ToVectorSearchable()). This would allow users to use EF to express arbitrarily-complex queries, and then "convert" them to an MEVD interface which can then be passed to e.g. a RAG framework.

This would likely rely on #36350 - a common, provider-agnostic way to perform vector search in EF. Otherwise, since every provider currently exposes its own specific mechanisms for expressing vector search, the ToVectorSearchable() operator would have to be provider-specific.

Note that this would probably need to be a separate package, as we don't want to push the reference to MEVD on all users.