Deprecate zookeeper-operator

Ref discussions in https://github.com/apache/solr-operator/issues/517#issuecomment-1428310490

The ZK operator is a project that is not well maintained ([74 open issues](https://github.com/pravega/zookeeper-operator/issues) and no response to PRs). They lag in releases (on zk 3.7.1 while latest is 3.9.0) and you cannot even upgrade Zookeeper by referencing another ZK docker image, since the zk-operator require their own custom image with some added tools. This *will* be a problem in the future unless pravega ups their game one this.

Other issues with the architecture:
* it is a bit awkward to have the Solr operator add a CRD for the Zk operator to pick up. Hard to debug issues.
* If you try to delete a solr cluster in e.g. ArgoCD, it will try to delete leaf resources first, not being aware that they are managed by ZK-operator, so ZK-operator will re-create them in an endless loop
* Upgrading Solr operator requires manual upgrading of zk-operator CRD in the right order..
* ZK-operator POD runs as root and there is no way to patch the pod-spec through Solr-operator :(

So let's consider declaring the zk-operator support deprecated. We can then either recommend users to use bitnami ZK chart separately and copy the ZK address. Or if possible, a tighter integration where you can just provide a namespace+name and let solr-operator figure out the connection string.

Start with the linked Solr Operator discussion and review the current Zookeeper-operator support before choosing an approach. Done would require a settled deprecation or replacement plan, including how users provide the Zookeeper connection and how existing deployments migrate.

Written by the indexing model from the issue text.