feat: Dependency locking

[mumoshu]

In order to maintain predictable deployments, as developer I want to generate and use "lock files" for all chart versions retrieved from a helmfile.

This change solves it by (1)enhancing helmfile deps to generate a lock file containing all the direct chart dependencies of each helmfile state file and
(2)making other helmfile sub-commands reads the lock file and merge the locked version numbers to the helmfile state file being processed.

The lock file is named after the helmfile state file being locked, so that you can have multiple set of the helmfile state file and the lock file pairs in a directory.

When helmfile deps are not explicitly run before commands like sync, all the helmfile behavior should remain as before.

Let's say you have helmfile.1.yaml:

repositories:
- name: stable
  url: https://kubernetes-charts.storage.googleapis.com

releases:
- name: envoy
  chart: stable/envoy
- name: envoy2
  chart: stable/envoy

helmfile deps generates helmfile.1.lock that looks like:

dependencies:
- name: envoy
  repository: https://kubernetes-charts.storage.googleapis.com
  version: 1.5.0
digest: sha256:e43b05c8528ea8ef1560f4980a519719ad2a634658abde0a98daefdb83a104e9
generated: 2019-05-14T16:45:37.78205+09:00

Under the hood, helmfile deps creates a temporary local helm chart with a dummy Chart.yaml and requirements.yaml deduced from the helmfile.yaml content, then runs helm dependency update to produce and update the corresponding requirements.lock file.

helmfile then renames it to match the name of the targeted helmfile state file and moves it, so that it becomes adjacent to each helmfile.yaml.

Other helmfile commands like sync, diiff, apply, lint read chart version numbers from the lock file.

Resolves #483
Resolves #563

[mumoshu]

Let's see how this works in the wild.