Environments currently have the concept of a server URI, but it is
ambiguous which cluster namespace to use.

This commit will introduce the concept of namespaces to the env
commands.

For example,
`kubecfg env add staging http://mock-staging-uri \
 --namespace=staging-namespace`
`kubecfg env set staging --namespace=staging-namespace`

The default environment will use the namespace of the default context.

This commit will also update commands that take the <env> arg such as
`apply` to make use of the env namespace, if specified.

When we run `init`, currently we generate a simple environment called
'default' with no URI. A better idea is to generate the URI from the
current context of the active kubeconfig file, if it exists.

For example, 'apply <env' currently operates as a no-op. With the
introduction of simple environments in PR #131, 'apply <env>' should
perform basic validation such that:

1. The user has added the environment that is being deployed against to
their Ksonnet project.

2. The URI in the environment's spec file that the user wishes to deploy
to should correspond to at least one cluster location as listed in
kubeconfig.

If either of those conditions are not satisfied, the kubecfg user will
receive the corresponding error.

In addition, this commit will set the kubectl --cluster flag to point at
the cluster listed by the environment URI.

This commit will add logging to all env subcommands 'list', 'set',
'add', and 'rm'. It adds both Info level and Debug level logging.

Fixes #137

'env set <name>' sets environment fields such as the name, and cluster
URI. It currently accepts the flags '--name' and '--uri'. Changing the
name of an environment will also update the directory structure in
'environments'.

'env rm <env-name>' deletes an environment within a ksonnet project.
This is the same as removing the <env-name> environment directory and
all files contained.  Empty parent directories will also be removed.

'env list' will list all environments within a Ksonnet project. Each
environment will be pretty-printed with it's name and cluster URI
location.

'env add <env-name> <env-uri>' will create a new environment within a
ksonnet project, by generating a new directory, 'env-name', within the
'envs' directory. Each environment will contain environment-specfic
files. Notably, a new environment-specific file is 'spec.json'.
'spec.json' currently only contains the 'env-uri' of the Kubernetes
cluster located at the added environment.

Below is an example directory structure for the environment
'us-west/staging':

app-name/
  .gitignore           Default .gitignore; can customize VCS
  .ksonnet/            Metadata for ksonnet
  environments/        Env specs (defaults: dev, test, prod)
    default/           [Default generated environment.]
    us-west/           [Example of user-generated env]
      staging/
        k.libsonnet
        k8s.libsonnet
        swagger.json
        spec.json      [This will contain the uri of the environment]
  components/          Top-level Kubernetes objects defining application
  lib/                 user-written .libsonnet files
  vendor/              mixin libraries, prototypes

This commit is a follow-up to the discussion in the ksonnet.next design
doc, in which users consistently expressed their preference that the
`update` command be called `apply`.

NOTE: We have renamed `pkg/kubecfg/update_test.go` ->
`pkg/kubecfg/apply_test.go`, but we copy the `update`'s integration test
file. The reason is that the `update` unit tests actually test things
like GC (rather than the command itself), so the file name is
inconsequential. On the other hand, the integration tests test the
commands themselves, so it is important to have two copies, one for
`update` and one for `apply`.

Currently, if the user wants to deploy a ksonnet application, and that
application uses some vendored library, or something in the `lib/`
directory, they will have to pass the appropriate `-J` flags into the
command themselves.

This commit will automatically add these whenever we're in an app
directory and a command is issued. In particular, even if the user
passes in the `-f` flag (rather than an environment name), we'll still
add library paths to the command if we're in a ksonnet app directory.
This is meant to capture the case that a user wants to update one
resource in particular in a ksonnet application.

This commit will separate the application level logic for the 'show', 'delete',
'validate', and 'diff' commands from the Cobra logic in the cmd/ package.  The
application level logic will be placed in pkg/kubecfg/.

The ksonnet.next design doc specifies the core kubecfg verbs (i.e., the
ones listed above) to all have the form:

  kubecfg <verb> [<env-name>|-f <file-or-dir>]

That is to say, each of these should be able to take either an
environment name, or a `-f` flag with a list of files and directories to
apply `verb` on. In the case of the environment, we will apply `verb` to
every component in the `components/` directory.

This commit implements this behavior for all these verbs.

This commit will implement the first version of the `init` subcommand.
This subcommand initializes a ksonnet application, including generating
the default directory tree and generating the appropriate ksonnet-lib.

Noticed and then audited in the course of other work.

This will make it possible to inject fake dependencies, once the fake
dynamic client makes it into a client-go release.

(other commands will be moved similarly in future PRs)