Currently spec.json contains detail about an environment's namespace and
server. Following the proposal at
design/proposals/modular-components.md, this change will consolidate
environment specifications in the common ksonnet app.yaml file.

An environment specification for the environment "dev", may look as
follows:

environments:
  dev:
    destinations:
    - namespace: foo
      server: example.com
    k8sVersion: "1.8.1"
    path: dev
    targets:
    - db

Note: This change currently doesn't support

(1) population of the k8sVersion field. This will occur as we migrate
the environment .metadata folder.
(2) deployment to more than one destination. This will occur once ks
supports multi-cluster deployment.
(3) setting of details other than the env name in `ks env set`. Prior
to this change, users are able to namespace and server URI, however it
becomes ambiguous which namespace is being set for an environment where
there can be multiple destinations. ...

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

Introduce `ks component rm <component>`. This functionality will:

1. Delete the component file from components/. This is determined by the
component file name. If there exists two files with the same name but
different file  extensions, we will error out.

2. Remove component references. This currently implies removing all
component referenes in the component/params.libsonnet file and the
environment-specific params.libsonnet files.

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

This adds a high level 'component' command and a 'component list'
command. 'component list' will pretty print all the components in
ksonnet application directory.

To accomplish this, an API is added to the metadata manager that returns
all components. Components are the individual files in /components, with
the path extension trimmed.

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

This adds a high level 'component' command and a 'component list'
command. 'component list' will pretty print all the components in
ksonnet application directory.

To accomplish this, an API is added to the metadata manager that returns
all components. Components are the individual files in /components, with
the path extension trimmed.

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

Currently users are unable to add their own registries through the CLI.
This limits them to a small subset of prototypes found in the default
incubator registry.

This commit will add the command `ks registry add`, that allows users to
add registries supporting the `github` protocol.

It will be of the form `ks registry add <registry-name> <registry-uri>
[--version]`. If a version is not specified, `latest` will be used.

Signed-off-by: Jessica Yuen <im.jessicayuen@gmail.com>

- Add message:  Creating a new app 'foo' at path '/path/to/foo'
- On success, add message:  ksonnet app successfully created! Next, try
  creating a component with `ks generate`
- On failure, provide suggestions for the user.
- Make note that the context is retrieved from the kubeconfig file at
  the environment variable $KUBECONFIG

Foreground colors were causing conflicts with user's terminal colors.
i.e. Black text would show as invisible for users with a black terminal
background.

Historically, every time we've needed to write out something tabular,
we've hand-rolled an ad hoc padded row writer. Yes, in each case. Such
is #startuplife.

The third time we did this we wrote this with bugs, and so now we are
rewriting it in a general, tested function, and transitioning all places
where we call this to use this function.

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'

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

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)