Add asynchronous support to WeaviateVectorStore through optional WeaviateAsyncClient (#233)

# Asynchronous support for WeaviateVectorStore 
This PR adds adds an optional
[WeaviateAsyncClient](https://weaviate.io/developers/weaviate/client-libraries/python/async)
to `WeaviateVectorStore.client_async` in order to fully support the
asynchronous methods implemented by the base
[VectorStore](https://github.com/langchain-ai/langchain/blob/e1af509966726d4f0831e6a54d794fd75c6d591d/libs/core/langchain_core/vectorstores/base.py#L59).
Closes: #207 

## Description
There is no proper support for the asynchronous methods on the
`WeaviateVectorStore`, as mentioned in Async client support #207 . The
`VectorStore` currently uses the `run_in_executor` langchain utility on
all the synchronous methods of the `WeaviateVectorStore`, leading to a
lot of resource warnings when used inside async context. This
implementation should solve these issues and lead to overall efficiency
improvements when used inside async context. The async tests run about
2x as fast compared to the original tests (~48s vs.~ 23s for me), even
though there are more of them.

I've attempted to implement this with backwards compatibility, so when
no `client_async` is passed along the default `client`, the methods
still call the synchronous methods in the same way the base vector store
currently does. Overall the test coverage has been increased to 98.66%
through mocking and error asserts.
 
Please let me know if any changes are required, there still seems to be
some room for improvements regarding shared logic between the sync/async
implementation. Another approach would be to support `client:
WeaviateClient | WeaviateAsyncClient` and decide which implementation to
use based on the type of client supplied. I took a brief look at this,
but it requires a lot of refactoring of the current implementation. This
approach will arguably result in cleaner and more efficient code as it
avoids the need to pass a sync client along with the async client.

---------

Co-authored-by: Duda Nogueira <dudanogueira@gmail.com>