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.

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.

The `prototype list` command lists all known prototypes. It is
functionally equivalent to a `prototype search` that returns all
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.

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