We decided that this would give the users too many options. We should
limit the documentation to Jsonnet.

When `generate` was first implemented, we made a conscious decision to
not include the `--help` flag, so that we would not accidentally break
templates with a parameter called `help`.

But, this is unintuitive for users who want to use the `--help` flag, so
in this commit we will print the help message if (1) there is a single
command argument, and (2) it is either `--help` or `-h`.

Fixes #21.

Currently, if a component name contains a special character, ex:
foo-bar, this translates to the jsonnet identifier: foo-bar, which is
invalid syntax.

This change will quote component names where there are special
characters.

This commit will append both mandatory and optional  prototype
parameters to the component params.libsonnet file on `ks gen foo ...`.

Default values will be used for optional params where the user does not
specify flags to `ks gen foo ...`.

Because we are trying to append to jsonnet, we will have to traverse the
AST to first identify the location of where to insert the new component
params. New components will be inserted at the bottom of the components
object, with the params ordered alphabetically.

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.