Before commit: a `Builder` object was required to calculate the
environment variables to pass to external scripts.

This is a nuissance when no `Builder` is available (e.g., when loading
an mfgimage, or for the upcomimg per-package commands feature).

After commit: Environment variables are divided into three sets (basic,
settings, slot).  The sets are divided according to the inputs required
to generate them.  Now the appropriate variables can be calculated
without a `Builder` object.

Prior to this change, ShellInteractiveCommand() would never return an
error.

Now, this function returns an error if the specified command exits with
a nonzero status.  This change makes the function consistent with the
other "shell command" functions in the util package.

It is simpler to just use `sort.Slice()` rather than create a sorter
type.

This commit adds the ability to run custom commands at build time.

This PR adds the ability to run custom commands at build time.

A package specifies custom commands in its `pkg.yml` file.  There are
three types of commands:
1. pre_build_cmds (run before the build)
2. pre_link_cmds (run after compilation, before linking)
3. post_build_cmds (run after the build)

Example (apps/blinky/pkg.yml):
```
pkg.pre_build_cmds:
    scripts/pre_build1.sh: 100
    scripts/pre_build2.sh: 200

pkg.pre_link_cmds:
    scripts/pre_link.sh: 500

pkg.post_build_cmds:
    scripts/post_build.sh: 100
```

For each command, the string on the left specifies the command to run.
The number on the right indicates the command's relative ordering.

When newt builds this example, it performs the following sequence:

* scripts/pre_build1.sh
* scripts/pre_build2.sh
* [compile]
* scripts/pre_link.sh
* [link]
* scripts/post_build.sh

If other packages specify custom commands, those commands would also be
executed during the above sequence.  For example, if another package
specifies a pre command with an ordering of 150, that command would run
immediately after `pre_build1.sh`.  In the case of a tie, the commands
are run in lexicographic order.

All commands are run from the project's base directory.  In the above
example, the `scripts` directory is a sibling of `targets`.

See <apache#335> for details.

We don't currently support custom commands in cmake output.  Print a
warning if the user runs the "target cmake" command on a target that
specified custom commands.