Using `Version()` as a string leaves a preprocessed version tag in the
ksonnet version. Construct a new version using the `Major` and `Minor`
fields. Adds short SHA1 from k8s.io/apimachinery as well. SHA1 is pulled
from `dep status`.

Re: #250

Signed-off-by: bryanl <bryanliles@gmail.com>

Signed-off-by: bryanl <bryanliles@gmail.com>

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

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

ksonnet.next is centered around the application directory structure
generated during init, however the integration tests are still tightly
tied to the model from kubecfg, where the '-f' flag was the standard and
environments were not introduced.

This commit will add test fixtures to mock a ksonnet application
structure, and rewrite the existing apply and delete tests to support
this new model.

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

Fixes #100.

This commit will transition the ksonnet CLI away from accepting either a
list of files or an environment (or both). A detailed explanation
follows.

Historically, the ksonnet CLI has had several "environment commands".
These commands (e.g., `apply`, `diff`, `delete`, `show`, etc.) all took
one of the following:

  1. An environment name. For example, `apply us-west/dev` will `apply`
     everything in the `components/` directory to the cluster denoted by
     `us-west/dev`.
  2. A set of files. For example, `apply -f foo.jsonnet -f bar.jsonnet`
     would apply those two specific Jsonnet files to the server
     specified by the current context in $KUBECONFIG.
  3. Both an environment name and a set of files. For example,
     `apply us-west/dev -f foo.jsonnet -f bar.jsonnet` would `apply`
     those two files to the cluster denoted by the `us-west/dev`
     environment.

This "duality" remained in place primarily because it was important ...

The Language Server Protocol (LSP) implements TextMate's "snippets"
feature. Originally imagined as a kind of Mad Libs for code, with users
given a code template and some number of "placeholder" blanks to fill
out, which was done by using tab to switch between them, LSP team
attempted to standardize this feature across language servers, so that
language authors had a well-specified interface to provide "snippets" to
any editor implementing the LSP.

Today, the LSP specification of TextMate snippets forms the bedrock of the
ksonnet prototype specification. Specifically, though users will
eventually be able to use Jsonnet to generate prototypes, they are
compiled down to the TextMate snippets specification.

This commit begins this process by introducing an implementation of the
LSP snippets specification, including both a parser and an evaluator.

For more details, see the extensive comment in `interface.go`.

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.

Currently contains basic "update" and "delete" tests.
More cases will be added in followup patches.

Much of the tooling build around ksonnet applications will be powered by
metadata presented in a structured directory format. This is similar in
principle to how Hugo and Rails structure web applications.

This commit will begin the process of introducing a FS-based state
machine that manages this directory structure. Primarily, this involves
introducing:

1. Init routines for the directory structure
2. Routines to search parent directories for a ksonnet application
   (similar to how git does this with repositories)

Initially, the directory structures looks like this:

  app-name/
    .ksonnet/   Metadata for ksonnet
    components/ Top-level Kubernetes objects defining application
    lib/        User-written .libsonnet files
    vendor/     Mixin libraries, prototypes

The `.ksonnet` file marks the application root, making it possible to
search parent directories for the root.

As time continues, more verbs will be introduced to manipulate this
metadata (including, e.g., vendoring dependencies, searching prototypes,
and so on).

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)

Fixes #35

Fixes #12

Basic skeleton.  Can evaluate jsonnet and show the output as yaml or
json .. and that's about it.