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.