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.

Fix improper elision of -J flags

Set default log level to 'Info'

Currently if we use a command like `apply default -f
components/whatever.yaml`, kubecfg will fail to emit flags that add
ksonnet-lib to the -J paths. This means that, while a command like
`apply default` will correctly linke against (e.g.) `k.libsonnet`,
adding the `-f` flag will not.

This commit will correct this problem for all commands of this form.

Commands using the <env> arg should deploy to the correct cluster

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.

Currently, commands take either an <env> or a '-f' argument but not
both. With this commit, we are allowing both args to be provided. The
behavior is expand the files passed by the '-f' flag and deploy the
objects to <env>.

Adopt 0755 as default permissions for folders

Under certain circumstances, it is possible for operations to fail
because of permissions that are too restrictive. Here we adopt the
default permissions of 0755 (i.e., rwxr-xr-x), which should be a better
balance of restriction and flexibility.

Add logging to 'env' subcommands

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

Add to 'env' command documentation

Currently 'Info' level logs are only shown with the '-v' flag. This
makes commands without the '-v' flag of little use to users, especially
on success cases, due to no output.

This commit will set the default log level to 'Info', and passing a '-v'
flag will log at a 'Debug' level.

Fixes #139.

Set default permissions in `metadata.Manager` to 0644

Currently all files and folders created with the `metadata.Manager`
(which is the core FS management subsystem) are created with permissions
0777, i.e., everyone has all permissions.

This commit transistions us to a more locked down permissions set, 0644,
which allows the user to do everything except execute, and everyone else
to only read.

Since we don't store any app code that needs to be executed, this should
be suitable for everything.

Fixes #136.

Introduce env subcommands 'env add', 'env rm', 'env set' & 'env list'

'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

Add types for prototype parameters

Fix #113

When a user runs `prototype search`, we'd like for the output to include
the name, description, and available template types, and we'd like that
output to be padded for readability. For example, if the user runs
`prototype search io.`, we'd like to output something like this:

   io.whatever.pkg.foo    Foo's main template    [jsonnet, yaml]
   io.whatever.pkg.foobar Foobar's main template [jsonnet,   yaml, json]

This commit will introduce this style of padded output to the `prototype
search` subcommand.

This commit will fix #116 by introducing two new constructs to the
prototype specification schema:

1. Mandatory types for prototype parameters. This lets us accept bare
   words on the command line, and then "do the right thing" when
   emitting JSON or Jsonnet.

   For example, say a template produces a `core.v1.Service` that exposes
   a port with a `--targetPort` flag. When the user passes a number
   (e.g., `80`) in, we should _not_ put quote marks around it, since we
   want to expose port `80`. When the user passes a string (e.g.,
   `"nginxPort"`), we _should_ put quote marks around it, to denote that
   we're exposing the port with that name.

   In order to do this, we need to know they "type" of the parameter (in
   this case, `NumberOrString`).

2. Mandatory template types. A template can have a JSON, YAML, or
   Jsonent flavor, and we default to using Jsonnet. This is useful
   mostly to make type parameters less error-prone (since one set of
   parameters corresponds to one set of templates), but it also
   significantly de-bloats the output of commands like `search`, since
   one fully-qualified name can correspond to multiple flavors of the
   same template.

This commit fixes #113, causing us to emit `k.libsonnet` (a collection
of extensions to the k8s API) by updating the dependency on
`ksonnet-lib/ksonnet-gen` and exercising the new signature for
`ksonnet.Emit`, which handles this automatically.

We update the `vendor/` directory and the code that depends on it in the
same commit so that we don't break bisect.

'init' should use current directory when generating Ksonnet app

Change directory structure generated by 'init' to support envs

This commit will remove the vendor/lib and vendor/schema directories
generated by 'init'. An 'environments' directory will be created from
the root app directory, with the default environment directory 'dev'
and it's containing contents rooted at 'environments'.

The intention of environments are to represent the deployment
environments of Kubernete clusters, with the following example
directory structure:

app-name/
  ..
  envs/
    dev/
    us-west/
      prod/
      staging/

Support import param rewrite for jsonnet snippets

Deprecate `update` subcommand; introduce `apply`

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`.

This commit will rewrite all parameters in the passed Jsonnet file of
the form `import param://foo` to `${foo}`. This will be a utility for
`ksonnet prototype use` to support LSP-spec-compliant snippet JSONs.

Include `lib/` and `vendor/lib` when expanding templates

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.

Disable yaml case until test can be rewritten

show_test has been failing intermittently since
af3f0f6c introduced `-f`.

The test failure is due to the flags not being completely reset
between `RootCmd.Execute()` invocations, thus the second of json/yaml
(changes because hash ordering) sees *duplicate* `-f` options, and
produces duplicate output.  This breaks json test validation, but
not yaml(!)

Ideally we would revert the offending change and resubmit with fixed
tests, but there have been numerous changes merged since. To stop
developing _further_ failure blindness, this change simply disables
the (less-strict) yaml testcase while a rewrite of show_test is
undertaken (probably a move to new integration framework).

This is *not* a fix for #99

Allow explicit --namespace to override value in kubeconfig context