ref(chartutil): move chart loading out of chartutil into new package
    add chart loader interface to allow lazy loading
feat(chart): create chart accessors
ref(*): cleanup requirements
ref(tiller): remove optional template engines
ref(tiller): simplify sorting releases and hooks
ref(*): code simplification
ref(hapi): move chart package out of hapi
ref(chart): add requirements and lock to Chart struct

To match the convention of `helm install`, `helm uninstall` is the inverse.

Other tangential changes in this PR:

- StatusDeleting has been changed to StatusUninstalling
- StatusDeleted has been changed to StatusUninstalled
- `helm list --deleted` has been changed to `helm list --uninstalled`
- `helm list --deleting` has been changed to `helm list --uninstalling`
- `helm.DeleteOption` and all delete options have been renamed to `helm.UninstallOption`

I have not made any changes to the "helm.sh/hook-delete-policy", "pre-delete" and "post-delete" hook annotations because

1. it's a major breaking change to existing helm charts, which we've commited to NOT break in Helm 3
2. there is no "helm.sh/hook-install-policy" to pair with "helm.sh/hook-uninstall-policy", so delete still makes sense here

`helm delete` and `helm del` have been added as aliases to `helm uninstall`, so `helm delete` and `helm del` still works as is.

`go test ./pkg/tiller -test.log`

Resolves #3655
We were seeing that when running helm upgrade with the reuse-values
flag enabled that you could end up in the position where overrides
a.k.a computed values from previous revisions were not being saved on
the updated revision. This left us in a weird position where some
computed values would disappear mysteriously in the abyss. That
happened because computed values from previous revisions weren't merged
with the new computed values every time the reuse-values flag was used.
This PR merges computed values from the previous revisions so you don't
end up in that kind of conundrum.

When using `helm upgrade --install`, if the first release fails, Helm will respond with an error saying that it cannot upgrade from an unknown state.

With this feature, `helm upgrade --install --force` automates the same process as `helm delete && helm install --replace`. It will mark the previous release as DELETED, delete any existing resources inside Kubernetes, then replace it as if it was a fresh install. It will then mark the FAILED release as SUPERSEDED.

Fixes #2437

Two bugs were causing this behavior

- Tiller was marking the previous release superseded when an upgrade
failed.
- Upgrade was diffing against failed releases

TestListReleasesByStatus -> tiller/release_list_test.go
TestListReleasesFilter -> tiller/release_list_test.go
TestListReleasesSort -> tiller/release_list_test.go
TestListReleases -> tiller/release_list_test.go
TestUpdateRelease_ResetReuseValues -> tiller/release_update_test.go
TestUpdateRelease_ResetValues -> tiller/release_update_test.go
TestUpdateRelease_ReuseValues -> tiller/release_update_test.go
TestUpdateReleaseNoChanges -> tiller/release_update_test.go
TestUpdateReleaseFailure -> tiller/release_update_test.go
TestUpdateReleaseNoHooks -> tiller/release_update_test.go
TestUpdateRelease -> tiller/release_update_test.go
TestRollbackReleaesFailure -> tiller/release_rollback_test.go