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.
Also we may be instantiating multiple clients - the kubectl use needs that (so you map restclients across multiple component plugins).  Builder just happened to be a convenient holder for that.  Having a simpler path for single client types isn't bad, and seems like that could be a simple static call.


> On Nov 24, 2014, at 3:31 PM, David Eads <notifications@github.com> wrote:
> 
> In pkg/client/clientcmd/doc.go:
> 
> > +You may obtain a copy of the License at
> > +
> > +    http://www.apache.org/licenses/LICENSE-2.0
> > +
> > +Unless required by applicable law or agreed to in writing, software
> > +distributed under the License is distributed on an "AS IS" BASIS,
> > +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> > +See the License for the specific language governing permissions and
> > +limitations under the License.
> > +*/
> > +
> > +/*
> > +Package cmd provides one stop shopping for a command line executable to bind the correct flags,
> > +build the client config, and create a working client. The code for usage looks like this:
> > +
> > +    clientBuilder := clientcmd.NewBuilder(clientcmd.NewDefaultAuthLoader())
> One of the issues today is keeping the flag names consistent across multiple different commands. That means that a BindFlags method is still required (or at least a call to create the flags). So we're looking having two calls no matter what we do.
> 
> By having an object holding that state information (the builder), we avoid having two discrete calls
> clientcmd.BindFlags(cmd.PersistentFlags())
> clientcmd.Client(cmd.PersistentFlags))
> that rely upon having two different methods being called with matching arguments. This is especially useful when you look at the common kubernetes usage that has methods trying to build clients relatively removed from the the point where the flags are bound.
> 
> —
> Reply to this email directly or view it on GitHub.
>