Support for deployment via helm

**Disclaimer**: I do love the separation of the smaller tools in carvel and am not an advocate of Helm's appoarch (monolithic tool, procedural, conditional on state, lookups etc.), but do want to see kapp-controller's approach used more widely. In particular, I'm a dev on the Kubeapps team and currently looking at options to support generic packaging (with an initial focus on supporting kapp, bundles, possibly kapp-controller) in addition to the current Helm support. If I can help kapp-controller to be more deployer-agnostic while not deviating from it's core principles, we could potentially use it instead.

**Describe the problem/challenge you have**

The output of `helm template` is not equivalent to helm support. It will only work for helm charts specifically written without use of any helm hooks or certain specific helm template functions.

## The case against `helm template`

Currently kapp-controller advertises support for Helm but it is actually support for a feature of helm - `helm template`. There are a number of issues with assuming that the output of `helm template` can be used to deploy a generic helm chart:

* From `helm help template`: "Any values that would normally be looked up or retrieved in-cluster will be faked locally. Additionally, none of the server-side testing of chart validity (e.g. whether an API is supported) is done."
* Related, as already mentioned in #33 , CRD's are not included by default in the output for a Helm 3 chart (as they're not templated) but can be included with `--include-crds`, though this doesn't solve the problem because...
* `helm template` renders and includes all templates within the chart, regardless of any helm-hooks (`pre-install`, `pre-delete`, `test`, `post-upgrade` etc). So for eg. if there are jobs for creating initial secrets using the pre-install hook, these will be included and overwrite an existing secret during an upgrade, or templates for testing the chart will always be included even though they should not be installed, or pre/post delete hooks etc. Yes it may have been better had Helm not provided (procedural) hooks in the first place, but the community uses them for ~~better or for~~ worse).

As a result of the above 3 points, kapp controller really only supports Helm charts which are specifically written to avoid depending on Helm (not a bad thing, but not really Helm support). People cannot expect to deploy their Helm chart successfully with `kapp-controller` (and I think `kapp-controller` docs should be specific about the requirements for helm support).

**Describe the solution you'd like**

I'd like to be able to specify a `deploy` directive in the [`App` spec](https://github.com/vmware-tanzu/carvel-kapp-controller/blob/develop/docs/app-spec.md) of `helm` and have helm do the install of the chart.

## The case for or against `helm upgrade --install` support

Most of the documentation for kapp and kapp-controller mentioning Helm seems to presume Helm 2 (and tiller) which has been dead for a while now (for example, [the kapp docs](https://carvel.dev/kapp/) mention "Can be used with helm charts, removing need for Tiller"). As you know, Helm 3 does not have any server-side component, so an application of a helm chart is done by the user (not a service-account of tiller etc.).

Similarly, Helm now includes the more declarative `helm upgrade --install` to output the desired state and though it is still not declarative due to hooks and certain template functions, it's a step in the right direction.

While I totally agree that `kapp` itself should not know anything but yaml templates, my question is whether `kapp-controller` could potentially be extended/generalised to support other deployment tools, such as `helm` (but not limited to `helm` necessarily) as an option for the deploy directive.

We could even (optionally) still have kapp create its config-map and ensure the labelling that kapp employs so that the `App` can still be removed or otherwise managed with via `kapp` and `kapp-controller` (as well as helm).

**Anything else you would like to add:**

I realise this would require a formal proposal, but wanted to just table the idea before investing in this direction. I'm guessing it's already been considered at some point but perhaps helm 3 changes some of the arguments. I realise helm 3 does not get away from the mashing of separate steps into one (template and deploy), but it might help to embrace the Helm community with first-class support :)