Deploy Helm release from a custom resource

[ccremer]

Summary

• Adds business logic to deploy the whole stack from CR to running PostgreSQL pod.
• Added test cases using plain testing framework if possible, or using envtest where needed.

Checklist

• [x] Categorize the PR by setting a good title and adding one of the labels: bug, enhancement, documentation, change, breaking, dependency as they show up in the changelog
• [x] Update tests.
• [x] Link this PR to related issues.

Reviewer Notes

• Before reviewing, review #24 first and ensure local env works for your OS (especially MacOS users, I don't own a Mac).
• This PR is based on #24, so gets the other one first so I can rebase afterwards, making the diff smaller.
• If you want to start reviewing by inspecting the end result, start by running make test-integration local-install install-samples
• Many advanced lifecycle features (e.g. Status conditions, events) currently missing - they shall be implemented in a later PR
• No detailed logs are printed yet
• Changing the sample and re-applying doesn't do anything once created (this is addressed later in another PR)
• Deleting the CR doesn't remove the Helm deployment (another PR)
• Reviewing by commit history should make it easier to understand since it's logical piece by piece. Though before submitting code feedback, compare with the end results as some stuff was reverted in the final state.
• I'm open for better name suggestions, but I will probably not apply them in this PR if it means to rewrite the whole history and instead apply in next PRs.
• I've already identified open Todo's, but I'll address them later.

[zugao]

I was able to test a bit differently the PR then the suggested approach make test-integration local-install install-samples. After simply issuing make local-install I created manually myself the CRDs and it turned out the ProviderConfig was missing which in the end prevented the postgresql instance to be deployed. After a short discussion with @ccremer we have agreed that it's ok at this step that the ProviderConfig would miss and the testing with samples was valid in the end. From my side the code looks good even though I had been missing some business logic that @ccremer gladly explained later to me.