When the user calls `ks init <whatever>`, we need to emit an `app.yaml`
for the new project. This commit will introduce such behavior.

Pretty prints differences between the component parameters of two
environments.

A component flag is accepted to diff against a single component. By
default, the diff is performed against all components.

Pretty prints component or environment parameters.

This command will display all parameters for the component specified. If
a component is not specified, parameters for all components will be
listed.

Furthermore, parameters can be listed on a per-environment basis.

Examples:

List all component parameters
  ks param list

List all parameters for the component "guestbook"
  ks param list guestbook

List all parameters for the environment "dev"
  ks param list --env=dev

List all parameters for the component "guestbook" in the environment
"dev"
  ks param list guestbook --env=dev`,

Parameters are the customizable fields defining ksonnet components. For
example, replica count, component name, or deployment image.

Parameters are also able to be defined separately across environments.
Meaning, this supports features to allow a "development" environment to
only run a single replication instance for it's components, whereas
allowing a "production" environment to run more replication instances to
meet heavier production load demands.

'ks param set' is defined as follows:
  'ks param set <component-name> <param-key> <param-value>'

Examples:

Updates the replica count of the 'guestbook' component to 4.
  'ks param set guestbook replicas 4'

Updates the replica count of the 'guestbook' component to 2 for the
environment 'dev'
  'ks param set guestbook replicas 2 --env=dev'

This commit will append both mandatory and optional  prototype
parameters to the component params.libsonnet file on `ks gen foo ...`.

Default values will be used for optional params where the user does not
specify flags to `ks gen foo ...`.

Because we are trying to append to jsonnet, we will have to traverse the
AST to first identify the location of where to insert the new component
params. New components will be inserted at the bottom of the components
object, with the params ordered alphabetically.

We are currently parsing system prototypes using the default TextMate
snippet which does not take into account the translation of params of
format `import 'param://foo`. The jsonnet snippet parser does take this
into account.

Expose the import path to environments/:env/params.libsonnet as an
ExtCode so that it is made accessible to component files during
expansion.

No need to redefine these flags as they are already specified in the
clientgo flag bindings.

'server' is consistent with what is used by clientgo. 'uri' only
introduces new language to ksonnet with the same meaning.

This change enables the user to diff between two environments that are
either local or remote.

i.e.,

`kubecfg diff local:dev local:prod` will diff between the expanded
templates for each environment on disk.

`kubecfg diff remote:dev remote:prod` will diff between two remote
environment clusters. It does this by first expanding the component
templates of each environment. Then, the live objects are fetched from
each of the clusters and the diff is performed against the live objects.

`kubecfg diff local:dev remote:prod` is also an option. This will diff
between the expanded templates for 'dev' on disk and the live objects
on 'prod's server.

For now, client-go bindings will be removed from the diff command.

Doing this because when diffing between multiple remote environments, it
becomes ambiguous which environment cluster the flags should belong to.

`ks env set foo --namespace=""` and `ks env add foo` will both set the
namespace to 'default' in the environment's spec.json file.

`ks env add myenv --context=dev` will initialize the environment URI
and namespace based on the context `dev`, as specfied in the
kubeconfig file. The same applies for `ks init foo --context=dev`.

If both the context and uri argument is not provided, the current
context is used.

This change will also remove uri as a mandatory arg in `ks env add`.
The uri will be moved to a flag. It cannot be used at the same time as
`context`.

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.

Commands that take `env` as a param currently expand all files in the
`components` directory. This is no longer necessary with the
introduction of `base.libsonnet` and the per-environment override
`<env>.jsonnet` file.

This commit will simply expand the single `<env>.jsonnet` file (which
will implicitly expand all component files). The case of running
`ksonnet apply default`, is equivalent to running `ksonnet apply -f
environments/default/default.jsonnet`.

base.libsonnet is a generated file that exists at the root of the
environments directory. This file is generated for all ksonnet projects.
The main goal of this file is to import all components in the components
directory, so that environments are able to easily extend / override any
one of these components in a modular structure.

The `clientConfig` param currently being passed is not needed, because
it exists as a package level var in root. It also makes little sense to
pass a custom `clientConfig` because if `overrides.Context.Namespace` is
populated, the namespace that is returned is configured as an override
in the package level `clientConfig` and not the `clientConfig` in the
param.

In order to support environment heirarchy, we need to be able to
reference all components. This commit will implement component imports
as k-v pairs ex: foo: "import/foo.jsonnet" as a Jsonnet object. This
jsonnet object will then be assigned as an ExtCode so that it can be
referenced by a base.libsonnet file which environments can build /
override upon.

Currently the command 'prototype use' expands a prototype and prints to
stdout. This is useful, but most of the time, users want to simply dump
the result in 'components/'

This command implements this print-to-stdout behavior in a new command,
'prototype-preview', and reimplements 'prototype use' to drop the
expanded prototype into 'components/'.

The new form of this command is:

  ksonnet prototype use <prototype-name> <component-name> [type] [flags]

So, for example, a command like:

  ksonnet prototype use deployment nginx-depl [...]

would expand the 'deployment' prototype, and place it in
'components/nginx-depl.jsonnet' (since Jsonnet is the default template
expansion). Alternatively, something like this:

  ksonnet prototype use deployment nginx-depl yaml [...]

would expand the prototype and place it in 'components/nginx-depl.yaml'
(assuming that there is a YAML version of this template.

Fixes #132.

Fixes #108.

The `prototype list` command lists all known prototypes. It is
functionally equivalent to a `prototype search` that returns all
prototypes.

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.

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.

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

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.

'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

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.