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

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

This has been a frequent area of client-go bugs, so add tests that
exercise --namespace handling in various scenarios.

If the current kubeconfig context is declared with an
explicit (non-empty) namespace, then `mergedKubeConfig.Namespace()`
returns that *config file* namespace value, ignoring an explicit
`--namespace` command line flag.

See https://github.com/kubernetes/client-go/issues/288 for upstream
client-go bug/discussion.

This change works around the issue by just checking the Namespace
override ourselves before falling through to the regular function.

Further fixes #103

Revert "Remove kubectl and Jsonnet flags from commands that don't use…

This reverts commit 020d5da0.

The change broke --namespace (and other flag) handling, because it
recreates the `clientConfig` global singleton multiple times - only
some of which are correctly tied to the relevant flags.

Introduce initial version of the `prototype` command

This commit implements `prototype` and its subcommands (i.e., `use`,
`search`, and `describe`) as specified in the ksonnet.next design doc.

This commit will introduce a simple skeleton of the `prototype` package,
which will (eventually) form the basis of the prototype command
(including the `search`, `describe`, and `use` subcommands as dictated
by the specification).

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

Refactor cmd/ application logic to pkg/

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

fix integration tests

The integration commit (#90) raced with another (#80) that changes the
`kubecfg` command line.  This commit adds the newly-required `-f` flag.

Add basic integration test framework

Fix README

Now the commands take either an env or a file, so let's at least fix the
README to make it work with files.

Implement `init`; bring synchronization primitives to spec

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 introduce the ability of the `metadata.Manager` to
report every file in the `components/` directory.

This is primarily useful when we invoke the Jsonnet VM, as it requires a
list of files to expand. (The `template.Expander` also handles YAML and
JSON.)

This commit will introduce the `template.Expander` abstraction, which is
meant to abstract over an invocation of the Jsonnet VM. Specifically, it
provides facilities for users to provide (e.g.) Jpaths, ext vars, and so
on.

The main justification for this change is:

* We need a common way for the `pkg` and `cmd` packages to interact with
  the Jsonnet VM.
* The `utils` package is already too much of a catch-all.
* It's easier to think about an invocation of the Jsonnet VM when we
  additionally encapsulate the parameters we pass to it on every
  invocation in kubecfg.

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.

`metadata.ClusterSpec` represents a specification for an abstract
Kubernetes cluster. For example, `version:1.7.0` represents a Kubernetes
cluster running a build from 1.7.0. This specification is primarily used
to generate ksonnet-lib.

This struct exposes a method, `data` that will retrieve the OpenAPI JSON
that specifies the API for a Kubernetes cluster. Eventually, `data` will
be able to read a file, pull from a URL, pull from a live cluster, or
pull a specific version of the API from the official Kubernetes
repository.

This commit introduces the the last of these options.

`metadata.Init` is meant to initialize a ksonnet application, including
its directory structure and the initial versions of various metadata
files in the tree. But, this implementation is incomplete: currently
only the directory tree is initialized.

This commit will change init to generate ksonnet-lib as part of the
initialization process.

The ksonnet-lib codebase exposes a package, ksonnet-gen, which will
automatically generate the ksonnet library for a given OpenAPI
specification of the Kubernetes API.

This commit vendors only the source in the ksonnet-gen package (rather
than the entire repository) as a dependency in the kubecfg project.

The codegen routines for ksonnet-lib depend on some Go 1.8 features
(e.g., `sort.Slice`). Once we vendor the dependency, this will cause the
build to fail perpetually for Go 1.7.

This commit therefore drops support for 1.7, making 1.8 the line of
supportability. This decision was made together with @anguslees, in
slack PMs.

Noticed and then audited in the course of other work.

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

Add application metadata management facilities

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

Despite being seemingly the most popular mockable FS library, Afero does
not tag releases in git, and does not appear to have cut a release in
about a year. Hence, the following considerations were taken into
account when we vendored the dependency:

* The commits since the last release (2015) appear to be almost entirely
  bug fixes.
* In the case that we are calling to the OS's FS (rather than, say, a
  testable, memory-mapped FS), the Afero is a simple wrapper, and hence
  introduces little risk into the CLI tool. We verified this by looking
  at the actual source.
* We opened issue #129 to attempt to nudge the committers into using
  stable software engineering practices (e.g., tagging your releases),
  and we will see how this issue evolves.

Implement `validate` subcommand