Add `return_embedding` param to `FilterRetriever`

[bilgeyucel]

Is your feature request related to a problem? Please describe.
It's not possible to remove the embeddings from the Documents that the FilterRetriever returns. These embeddings fill up the memory and context limit for LLMs if retrieved docs are passed directly to an LLM in Agent

Describe the solution you'd like
have return_embedding param for FilterRetriever like we have in other retrievers

Describe alternatives you've considered
Based on the architectures, there are different approaches to eliminate this, such as using outputs_to_string in Agent

Additional context
N/A

[sjrl]

Maybe to add to this, not only should we add this option to the FilterRetriever but we should also add it to InMemoryDocumentStore.bm25_retrieval since often times we use BM25 retrieval even on documents that have embeddings.

One thing I noticed is that filter_documents used by FilterRetriever is a part of our DocumentStore protocol. So we will need to think if we add return_embedding to the protocol and force all downstream DocumentStore's to update or find a more flexible way to expand the protocol.

Update:
As an alternative we could follow a similar approach as is used by the OpenSearchDocumentStore where we add a return_embedding parameter to the init method of InMemoryDocumentStore and use that within the necessary methods like bm25 retrieval, filter documents, and embedding retrieval