add utility for binding flags and building api server clients

This utility provides one stop shopping for a command line executable to get bind the correct flags, build the client config, and create a working client.  The code for usage reduces to something like this:

	authLoader := &PromptingAuthLoader{os.Stdin}
	clientBuilder := clientcmd.NewClientBuilder(authLoader)
	clientBuilder.BindFlags(cmds.PersistentFlags())
	apiClient, err := clientBuilder.BuildClient()

I made the flags congruent with kubectl and used kubectl as an example spot for usage.  This makes use of the auth config work in #2340 and the Bind and Build approach could be used to unify client creation and flag names.

@smarterclayton You've had an interest in this area.
The counter argument here is that having 29 different flag names for the same security params is worse.  This was mostly targeted at that.  And if master doesn't have consistent meaning across our commands (kubelet, proxy, client), that's just as confusing


> On Nov 26, 2014, at 5:22 PM, Tim Hockin <notifications@github.com> wrote:
> 
> In pkg/client/clientcmd/client_builder.go:
> 
> > +	"fmt"
> > +	"os"
> > +	"reflect"
> > +
> > +	"github.com/spf13/pflag"
> > +
> > +	"github.com/GoogleCloudPlatform/kubernetes/pkg/api/latest"
> > +	"github.com/GoogleCloudPlatform/kubernetes/pkg/client"
> > +	"github.com/GoogleCloudPlatform/kubernetes/pkg/clientauth"
> > +	"github.com/GoogleCloudPlatform/kubernetes/pkg/version"
> > +)
> > +
> > +// Builder are used to bind and interpret command line flags to make it easy to get an api server client
> > +type Builder interface {
> > +	// BindFlags must bind and keep track of all the flags required to build a client config object
> > +	BindFlags(flags *pflag.FlagSet)
> As an example of why I dislike it: skydns uses our BindFlags... and they end up with a flag called -master. That is a thoroughly UNHELPFUL flag name. It should have been --kubernetes-master or something. We can not, in a library, predict what flag names will make sense in an app, and we should not pretend we can.
> 
> —
> Reply to this email directly or view it on GitHub.
>