Feature flag to allow Golang implementations of gitlab-shell functionality to be selected

As a first step toward rewriting gitlab-shell in Go, we need a bin/gitlab-shell binary that can service commands with the existing Ruby binary, or switch to experimental Go reimplementations of the same functionality if requested in the configuration file.

---

(original description):

Because of the way bin/gitlab-shell integrates with sshd it is a disadvantage that we use Ruby. It depends on the Linux distribution how you can make sure that bin/gitlab-shell uses the right Ruby runtime. We have been avoiding this problem by making sure that bin/gitlab-shell works with any Ruby runtime on the system: we don't use Bundler, and no third-party C extensions. (Both of these are tied to the Ruby runtime.)

In omnibus-gitlab we solve this by rewriting all ruby scripts in gitlab-shell during the build, to use the Ruby runtime embedded in omnibus-gitlab. But we still support installations from source and the way we organize GitLab itself is that everything should be able to run without Omnibus.

This idea is relevant because we chose to build gitaly using gRPC, which needs a C extension on Ruby. The Go version of gRPC is native, meaning that we can trivially compile a static executable with a gRPC client in it. Our current plan is to make a command-line gitaly client, and to make that client a dependency of gitlab-shell. This is the same approach we used to use with Redis (gitlab-shell/hooks/post-receive use to shell out to redis-cli). We no longer use redis-cli because we figured out we could vendor the Redis gem because it is native Ruby (no C extensions).

Over time I have heard several people (@brodock, @bjk-gitlab, @vsizov ) suggest it would be nicer if bin/gitlab-shell and the hooks were re-written in Go because then we can use any third-party library we want (as long it is native Go code) and integration with sshd becomes less problematic.

This issue is meant for discussion of this idea.