Publish svcat binaries during CI

[carolynvs]

This is a follow-on from #1664.

• Set the version and commit fields in ./cmd/svcat during a build using LDFLAGS. We may need to discuss if we want to use the same tags for both svcat and the rest of the repo, otherwise people will definitely run into version bumps caused by svcat where no changes were made in say apiserver which could be confusing. One option is to make a new tag, like svcat-1.0.0 and use those to manage the binary version.
• Cross compile svcat for each supported platform. See https://github.com/Azure/service-catalog-cli/blob/master/Makefile#L6 for what we used before.
• Publish the binaries. One option is to publish to github releases page, and use a moving tag, like svcat-latest, in order to provide a stable download link for the docs.
• Update the install doc for svcat with the new links.

[carolynvs]

I can't make next Monday's sig meeting but it would help to figure out where to publish the svcat binary. Here are the options I see:

1. Continue publishing to Azure storage, links stay the same, and we can reuse the upload code from https://github.com/Azure/service-catalog-cli/blob/31a1c340ec13263391eebc2775dc5b4d7c9f6e67/Makefile#L60-L63
2. Publish to this repository's github releases and use a moving tag+release, e.g. svcat-v1.0.0, to provide a stable download link.

[MHBauer]

Is there a dockerfile? We can make an image and then suggest a bash alias for use. @duglin has some tips for doing this, I know.
Just like how we run go as a docker cmd, we can have svcat aliased to an image and bam, go go go.

[carolynvs]

@MHBauer It would be cool to publish a docker image of svcat, and tell people how to run it automatically using a bash alias, or Jess Frazelle-esque bash shenanigans.

We'll still need published binaries for the huddled masses who don't run everything in containers though. 😀

[MHBauer]

Agree we need a binary, just want to add it to the list.

[carolynvs]

Fixed by #1725