Semtantic versioning of both BinderHub as a package and the Helm chart

[consideRatio]

I had a chat with @betatim today, and I really think it's worth the effort and complexity to start version controlling both BinderHub and the Helm chart separately.

There are several reasons this can benefit us, but at this point I think the most pressing matter is to make development in this repo less coupled to the operation of mybinder.org-deploy. By having releases and changelog, we would provide mybinder.org with better information about changes that would be deployed when bumping a Helm chart version.

Is this an effort acceptable to pursue? If so, there are technical complexities to outline and resolve that can be discussed.

[manics]

I think it's a good idea, though I'd start by getting a stable version of BinderHub out. We'll need to do some API development work first, mostly related to #1318

Once it's released I think looking at decoupling the Helm Chart makes sense. Or were you thinking of decoupling it now?

[consideRatio]

We've discussed this in the January team meeting, and we decided to work towards it!

@manics about decoupling helm chart and binderhub python package - I don't want to work towards that as part of getting them both versioned together initially.

Our version bumps and changelog should reflect changes to either python package or helm chart, where we should try help clarify if something is helm chart specific I think.