feat: Add /ready endpoint to WebhookServer

[xeniape]

Description

Part of stackabletech/issues#828

This PR adds a /ready endpoint to the WebhookServer to be used by startup probes in the operators. It was added to the WebhookServer as per requirements of the ticket above, for the future and if more readiness checks come up unrelated to the CRDs and/or WebhookServer, it might be reasonable to start a separate server instead. Currently, if no webhooks were defined, the ready endpoint also would not be served (not the case with the current operators, as they all have webhooks).

As part of this the crd_established signal was also adjusted (timeout removed) because the timeout there would bite with the probes configuration. Instead of shutting down the whole controller on a crd_established timeout, the startup probe would now handle the checking and restarting.

The implementation was tested with the zookeeper-operator, changes there would then only include creating and passing a HealthCheckRegistry and marking checks as passed on crd_established signals. (few lines) -> part of the rollout later
After the rollout to the operators, the probes need to be added to the operator Deployments.

Definition of Done Checklist

• Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
• Please make sure all these things are done and tick the boxes

Author

• Changes are OpenShift compatible
• CRD changes approved
• CRD documentation for all fields, following the style guide.
• Integration tests passed (for non trivial changes)
• Changes need to be "offline" compatible

Reviewer

• Code contains useful comments
• Code contains useful logging statements
• (Integration-)Test cases added
• Documentation added or updated. Follows the style guide.
• Changelog updated
• Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

• Feature Tracker has been updated
• Proper release label has been added

[Techassi]

I like the overall mechanism of this, nicely done! I only have a few suggestions to slightly optimize it. And I also have a few thoughts on where code is located.

All my suggestions target only code, so when (and if) they are applied, the doc tests need to be adjusted as well.