Rewrite helm operator to use same git code as fluxd

[squaremo]

The go-git package seems to introduce a host of problems, especially
with SSH, that are obviated by using the git binary.

Given a couple of modest additions to github.com/weaveworks/flux/git,
we can use that instead. Namely: read-only repos, and repo "exports"
(that is, clones that come with only the ability to look at the
files). Those changes are introduced in #1238.

It also turns out that it's possible to simplify the chartsync and
releasesync packages. Given the whole picture in the existing code,
it's possible to boild it down to two mechanically simple processes:

• chartsync looks for the charts used by FluxHelmRelease resources,
  and checks whether they've changed since the last commit;
• releasesync installs any FluxHelmRelease resources that
  don't have corresponding releases, and upgrades any that do and
  differ.

(In fact, just the latter would be fine since new commits would result
in release diffs; but it's more eventual than having both).

Since these are now fairly compact, I've just merged them into the
chartsync package. I've removed the releasesync_tests.go here, since
it tested internal machinery that no longer exists, but I ought to
replace the test coverage forthwith.

(Once #1238 is merged, I'm going to play the 'it's an alpha' card and merge this too. Comments welcome in the mean time.)

[oliviabarrick]

Can we expose the ReadOnly setting to fluxd as well? It would be useful to be able to run read-only fluxes as well. Maybe that deserves a separate PR, though.

[squaremo]

Can we expose the ReadOnly setting to fluxd as well? It would be useful to be able to run read-only fluxes as well.

I had that half in mind as I wrote this stuff -- it'd be cool to have, say, --git-readonly make it just sync things, and not run automation etc. It would require a bit of finessing though, since for example, we use a tag in the upstream repo to mark which commits we've seen.