Use a more fitting error type

Currently this crate uses anyhow, which is usually meant for applications, not libraries. This makes it very hard to match on an error, because the error is essentially opaque. As far as I can see, we mostly return ´tonic::Status`, but there may be some APIs that also can return other errors.

The classic way of dealing with this is create a newtype that wraps Status, has a From<Status> impl and allows basically the same functionality (especially matching on Code). We could also create an enum instead, but I should note that this will either make the implementation, the user interface or both needlessly complex. If we have API calls that can return other errors, either have them return their own specific error type or convert whatever error we get to our predefined error type internally.

Another way would be to make the error type opaque, but that has the downside of making it harder for users to implement From<QdrantError> for their own error types, essentially requiring a Box or other indirection.

The issue names no files or tests; start by locating the crate's anyhow return types and APIs that return tonic::Status. Inventory any other returned errors before choosing between a wrapper and an enum. Done means an agreed public error design with matching, conversion, and user-facing behavior covered.