extracts ksonnet generator to a new package to make it easier to incorporate in new code

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

Dependencies in a ksonnet application are installed from collections of
packages called registries. In order to be precise about which packages
an app depends on, and where they are from, we have an API that
specifies each of these nouns.

Unfortunately, we never hooked up code to verify the versions of these
specifications as we deserialize them.

This commit will correct that.

Signed-off-by: Alex Clemmer <clemmer.alexander@gmail.com>

Partially implements the proposal
[here](https://github.com/ksonnet/ksonnet/blob/master/design/proposals/explicit-environment-metadata.md

)

Fixes #222

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

Currently the component APIs are grouped into the same file as
manager.go. As more component APIs are added, managers.go will be
difficult to maintain. Similar to the environment and registry APIs,
component APIs will be moved into a separate file component.go

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

Currently the component APIs are grouped into the same file as
manager.go. As more component APIs are added, managers.go will be
difficult to maintain. Similar to the environment and registry APIs,
component APIs will be moved into a separate file component.go

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

- Add message:  Creating a new app 'foo' at path '/path/to/foo'
- On success, add message:  ksonnet app successfully created! Next, try
  creating a component with `ks generate`
- On failure, provide suggestions for the user.
- Make note that the context is retrieved from the kubeconfig file at
  the environment variable $KUBECONFIG

Currently, creating a `dev` environment will create a file
`dev.jsonnet`. Creating a `prod` environment will create a file
`prod.jsonnet`. This is a little more complex and prone to error than it
needs to be, especially when we are renaming environments. It will also
make this file easier to refer to in documentation if we give the file a
static name -- `main.jsonnet`.

Fixes #48.

Currently the structs `app.Spec`, `registry.Spec`, and `parts.Spec` are
all serialized and deserialized using JSON instead of YAML.

This commit will resolve this issue.

This resolves the first half of #68. When we `generate` using a
prototype from a vendored dependency, it often results in a compilation
error when we `apply`, because these prototypes usually depend on code
that exists in the dependency, and `vendor/` is not a part of the
Jsonnet search path.

This commit resolves this problem by adding it to the search path.

The ksonnet project exposes a "default" registry, `incubator`, in the
ksonnet/parts repository.

This commit will cause ever `ks init` command to automatically add this
registry to the ksonnet application.

The vast majority of ksonnet apps will know about at least one registry,
the official ksonnet `incubator` registry. In general, managing
registries can involve fairly complex logic (e.g., resolving a reference
to a registry to a remote registry specification; finding all
libraries exposed by a registry; and so on).

This commit will introduce the `registry.Manager` abstraction, as well
as an implementation for registries hosted as GitHub repositories.

When the user calls `ks init <whatever>`, we need to emit an `app.yaml`
for the new project. This commit will introduce such behavior.

The goal of this commit is to add an interface to `metadata.Manager`
that allows retrieving of all environment params:
`getEnvironmentParams(envName)`.

This is done by:

1. Adding functionality to the snippet parser to get all environment
params out of the snippet read from
`environments/<env>/params.libsonnet`

2. Adding functionality to the snippet parser to get all component
params out of the snippet read from `components/params.libsonnet`

3. Having the `metadata.Manager` implementation handle the 'joining' of
params from 1) and 2), and returning that result.

This commit will add an interface `GetComponentParams` to
metadata.Manager that returns a map of parameters for the passed in
component.

Also implements the logic for parsing the jsonnet snippet to retrieve
the parameters.

This functionality will later support new commands to list parameters.

This commit will:

1. Add an interface `SetComponentParams` to metadata.Manager that takes
a list of parameters and sets those fields for the given component.

2. Add the jsonnet snippet manipulation logic that does the
'setting'. Parameters are set by:

a. Keeping track of the parameters that are to be modified / added --
this defaults to the parameters provided to us.
b. Discovering the current parameters in the existing snippet.
c. Adding any parameters from (b) that is not in (a).
d. Swapping out the old parameters with (c) in the snippet based on
the location text span, and returning the new snippet.

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.

Expose the import path to environments/:env/params.libsonnet as an
ExtCode so that it is made accessible to component files during
expansion.

The purpose of this file is to allow re-parameterization of components
after they are created.

`components/params.libsonnet` is generated on `ks init`. This file will
contain a jsonnet obj containing two objs:

1. global: contains user-defined global parameters; accessible to all
component and environments.
2. components: contains component-level parameters, defined initially
from `ks prototype use ...`

These objs are empty by default.

Environments currently have the concept of a server URI, but it is
ambiguous which cluster namespace to use.

This commit will introduce the concept of namespaces to the env
commands.

For example,
`kubecfg env add staging http://mock-staging-uri \
 --namespace=staging-namespace`
`kubecfg env set staging --namespace=staging-namespace`

The default environment will use the namespace of the default context.

This commit will also update commands that take the <env> arg such as
`apply` to make use of the env namespace, if specified.

Commands that take `env` as a param currently expand all files in the
`components` directory. This is no longer necessary with the
introduction of `base.libsonnet` and the per-environment override
`<env>.jsonnet` file.

This commit will simply expand the single `<env>.jsonnet` file (which
will implicitly expand all component files). The case of running
`ksonnet apply default`, is equivalent to running `ksonnet apply -f
environments/default/default.jsonnet`.

base.libsonnet is a generated file that exists at the root of the
environments directory. This file is generated for all ksonnet projects.
The main goal of this file is to import all components in the components
directory, so that environments are able to easily extend / override any
one of these components in a modular structure.

This change simply hides the environment metadata details that we do not
want users directly modifying into a .metadata folder.

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.

When we run `init`, currently we generate a simple environment called
'default' with no URI. A better idea is to generate the URI from the
current context of the active kubeconfig file, if it exists.

Under certain circumstances, it is possible for operations to fail
because of permissions that are too restrictive. Here we adopt the
default permissions of 0755 (i.e., rwxr-xr-x), which should be a better
balance of restriction and flexibility.

Currently all files and folders created with the `metadata.Manager`
(which is the core FS management subsystem) are created with permissions
0777, i.e., everyone has all permissions.

This commit transistions us to a more locked down permissions set, 0644,
which allows the user to do everything except execute, and everyone else
to only read.

Since we don't store any app code that needs to be executed, this should
be suitable for everything.

Fixes #136.

'env set <name>' sets environment fields such as the name, and cluster
URI. It currently accepts the flags '--name' and '--uri'. Changing the
name of an environment will also update the directory structure in
'environments'.

'env list' will list all environments within a Ksonnet project. Each
environment will be pretty-printed with it's name and cluster URI
location.

'env add <env-name> <env-uri>' will create a new environment within a
ksonnet project, by generating a new directory, 'env-name', within the
'envs' directory. Each environment will contain environment-specfic
files. Notably, a new environment-specific file is 'spec.json'.
'spec.json' currently only contains the 'env-uri' of the Kubernetes
cluster located at the added environment.

Below is an example directory structure for the environment
'us-west/staging':

app-name/
  .gitignore           Default .gitignore; can customize VCS
  .ksonnet/            Metadata for ksonnet
  environments/        Env specs (defaults: dev, test, prod)
    default/           [Default generated environment.]
    us-west/           [Example of user-generated env]
      staging/
        k.libsonnet
        k8s.libsonnet
        swagger.json
        spec.json      [This will contain the uri of the environment]
  components/          Top-level Kubernetes objects defining application
  lib/                 user-written .libsonnet files
  vendor/              mixin libraries, prototypes

This commit fixes #113, causing us to emit `k.libsonnet` (a collection
of extensions to the k8s API) by updating the dependency on
`ksonnet-lib/ksonnet-gen` and exercising the new signature for
`ksonnet.Emit`, which handles this automatically.

We update the `vendor/` directory and the code that depends on it in the
same commit so that we don't break bisect.

This commit will remove the vendor/lib and vendor/schema directories
generated by 'init'. An 'environments' directory will be created from
the root app directory, with the default environment directory 'dev'
and it's containing contents rooted at 'environments'.

The intention of environments are to represent the deployment
environments of Kubernete clusters, with the following example
directory structure:

app-name/
  ..
  envs/
    dev/
    us-west/
      prod/
      staging/

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.

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

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

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