Set individual environment variables for build

[scothis]

pack allows setting build-time environment variables via a file, but not
as individual values on the cli. This PR adds the ability to set one (or
more) environment variables directly as cli switches.

The same semantics are preserved from --env-file where a value can be
forwarded from the current environment if a variable name is specified
without a value. The new flags can be used to augment or override
specific values from a file.

The BuildFlags struct now includes an Env field in addition to EnvFile.
The BuildConfig struct EnvFile field has been renamed to Env for
consistency as the field contains the parsed values and not a file.

Refs buildpacks/roadmap#25

[scothis]

A little background context.

riff currently uses a riff.toml file to pass configuration to function buildpacks. This file is generated based on values provided to the riff cli. Since this config file is not actually part of the project, it's awkward to write a file to the filesystem, do some work and then remove that file. It would be nicer to specify this config as environment variables.

[scothis]

Merged master and fixed a conflict with build config changes.

cc @ekcasey

[ekcasey]

@scothis I was under the impression that riff was importing github.com/buildpack/pack as a library using the pack.Build(...) function to run builds. In which case, I would imagine the correct solution for this problem is to add a map of env vars as a param to pack.Build. In that case riff should be able to construct that map as desired (no file required).

Is riff shelling out to the pack cli? I am not opposed to supporting a --env flag but to better enable library consumers it's important to us to know where users are integrating. In the near future we plan to make everything except a deliberately exposed library internal and thus not importable.

[scothis]

@ekcasey yes, riff embeds pack rather than shelling out. On its own, this PR is not enough to fully solve riff's needs, but it provides a large step towards scratching that itch. I'll open another PR that takes a baby step towards creating a programatic API that exposes the same capabilities.

This PR is updated to resolve conflicts.

[ekcasey]

@scothis Thanks for the explanation. If we think cli users will value having a --env flag in addition to an --env-file, flag this is a good step.

I think the only thing missing here is acceptance test coverage. If we are exposing a new flag we should add coverage in acceptance/acceptance_test.go, just like we do with --env-file.

[scothis]

@ekcasey added an acceptance test and manually verified that all the tests are actually passing