Centralized management of container image versions

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

**Is your feature request related to a problem? Please describe the problem.**
Currently, container image versions are hard-coded directly in C# code, for example:

```csharp
internal static class QdrantContainerImageTags
{
/// docker.io
public const string Registry = "docker.io";

/// qdrant/qdrant
public const string Image = "qdrant/qdrant";

/// v1.14.1
public const string Tag = "v1.14.1";
}
```

This approach creates a maintenance burden—when a new container version is released, updates require manual code changes and redeployment.

### Describe the solution you'd like

Move container image version definitions into a centralized configuration file (similar to .NET’s Central Package Management). This file could be:

- Read at runtime or build time to apply the appropriate image versions.
- Integrated with tools like Dependabot to automatically detect and propose updates when a new container image version is released.

**Benefits:**

- Easier version management without modifying source code.
- Reduced risk and code churn.
- Automatic update suggestions and version tracking.

### Additional context

- Moving version definitions into a configuration file decouples version upgrades from code changes.
- Integration with version-bumping tools (e.g. Dependabot) can streamline updates and reduce manual effort.
- Similar approaches exist in package management ecosystems; applying this pattern to container images aligns with best practices.
- Decouples version updates from code changes.