scripts: fixes/improvements to regenerate.sh / install_protoc.sh

[dfawley]

There's some weird interactions going on, and some things I might like to see changed:

• install_protoc.sh checks the protoc version in your path before downloading, and refuses to download if your path's protoc is a different version than you'd like to install
• A function called download_binary shouldn't do other checks; those checks should be moved elsewhere.
• This line makes no sense:

  grpc-go/scripts/install_protoc.sh

  Line 63 in 45d44a7

  INSTALL_PATH=${1:+"$1"}

• This line needs quotes:

  grpc-go/scripts/regenerate.sh

  Line 54 in 45d44a7

  source ./scripts/install_protoc.sh $WORKDIR

• This line probably needs export in case a GOBIN isn't already exported:

  grpc-go/scripts/regenerate.sh

  Line 27 in 45d44a7

  GOBIN="${WORKDIR}"/bin

  (go install needs to be able to read it.)
• regenerate.sh calls install_protoc.sh after several other things have been done.
• regenerate.sh apparently tries to "save your $PATH", but since it shouldn't be executed via source there's no need to do any of this.
• Super nit-picky: install_protoc.sh sources vet_common.sh but is not a vet* script. Maybe rename vet_common.sh to common.sh?

IMO one of three models for these scripts seems pretty reasonable:

1. Always download everything into a temp directory.

• Downside: needs to download/recompile every time regenerate is run

2. Check the versions in your path and print help/commands to update them to the needed versions.

• Downside: it's hard to know where the user would want protoc to live.

3. Carve out a directory like $HOME/grpc-go-tools or $HOME/tmp/grpc-go-tools or something and download the tools there if the versions don't match.

• Downside: you're potentially polluting the user's directory.

Of these, I think I prefer (2) but am not strongly opposed to any of them. It looks like the scripts were already trying to implement (1), which is okay but is my least favorite option.

cc @arvindbr8 @aranjans