New version format doesn't work with helm 3

[manics]

Testing with the latest binderhub helm chart dev releases:

$ helm version`
version.BuildInfo{Version:"v3.0.0", GitCommit:"e29ce2a54e96cd02ccfce88bee4f58bb6e2a28b6", GitTreeState:"clean", GoVersion:"go1.13.4"}

$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "jupyterhub" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈ 

This works:

helm upgrade binder-test jupyterhub/binderhub --install --version=0.2.0-c04966f --namespace=binder-test -f secret.yaml -f config.yaml

This fails:

helm upgrade binder-test jupyterhub/binderhub --install --version=0.2.0-028.9ba1fc3 --namespace=binder-test -f secret.yaml -f config.yaml
Error: failed to download "jupyterhub/binderhub" (hint: running `helm repo update` may help)

This also fails:

$ cd helm-chart/binderhub/
$ cat requirements.yaml 
dependencies:
- name: jupyterhub
  version: "0.9.0-alpha.1.071.b0d70c2"
  repository: "https://jupyterhub.github.io/helm-chart"
$ helm dependency update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "jupyterhub" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈Happy Helming!⎈
Error: dependency "jupyterhub" has an invalid version/constraint format: constraint Parser Error

[consideRatio]

Whaaaaat nooooooo! Arrrgh the second helm issue with version parsing... Sigh this should be valid!

[consideRatio]

This is the Helm code base that cause the error:
https://github.com/helm/helm/blob/0edb09e4faaed3c7ed5b1f843815f625fa3b7c06/pkg/downloader/manager.go#L228-L231

This is a regression of masterminds/semver version 3+ as can be seen in this Go playground: https://play.golang.org/p/XcOuf-z_y6v

[consideRatio]

Complicated... Apparently it isnt OK according to SemVer to have a identifier, which is the sections between the dots, that is numeric and leads with a zero. This create an issue both for our commit-number since release and for the git hash. The git hash can be fully numeric with a leading zero if we are unlucky. I have been unlucky with regards to it being totally numerical before...

My suggestion, is that we change the specification once again to resolve this, to make it on of the below:

• 0.9.0-alpha.1.n095.3e95dc3 - Ignore risk for numeric sha with leading zero
• 0.9.0-alpha.1.n095.g3e95dc3 - Let there be a leading g as is actually passed by the git describe command to indicate it is a git hash.
• 0.9.0-alpha.1.n095.sha3e95dc3 - Let there be a three letter "sha" leading the git hash to realize that you should exclude the leading "sha" easier if you want to find the corresponding git commit, which is not at all obvious if you need to figure out you need to remove a single letter g from a mash of alphachars that can contain g and vary in length.

I lean towards the first or third option. What do you think @manics and @betatim ?