Add support for buildpack api 0.8

[samj1912]

Resolves #128

[dmikusa]

Looks good to me.

I'm not 100% sure it's necessary, but my only observation is that in the detect & build tests, we're not testing the case where both args & env variables are set.

I believe that the code is going to take the env variables if both are set. It's an invalid state, so it would seem reasonable if we errored if both are set. I don't know if the platform/lifecycle would allow this (I didn't test), but my line of thinking is that it might be possible for a user to set one of these new env variables on an older platform/lifecycle since the older platform/lifecycle is unaware of them altering the behavior. In this particular case, erroring out would be beneficial.

[dmikusa]

Suggested change

	logger.Debugf("Layers: %+v", ctx.Layers)
	logger.Debugf("Layers Directory: %+v", ctx.Layers)

[samj1912]

Is it okay if we keep it to the previous statement since that is what libcnb was logging before?

[dmikusa]

Oh, I thought that had changed in the diff. Yes, not a huge issue. Just thought that would be a little clearer.

[samj1912]

Looks good to me.

I'm not 100% sure it's necessary, but my only observation is that in the detect & build tests, we're not testing the case where both args & env variables are set.

I believe that the code is going to take the env variables if both are set. It's an invalid state, so it would seem reasonable if we errored if both are set. I don't know if the platform/lifecycle would allow this (I didn't test), but my line of thinking is that it might be possible for a user to set one of these new env variables on an older platform/lifecycle since the older platform/lifecycle is unaware of them altering the behavior. In this particular case, erroring out would be beneficial.

Even if the user sets this on an older version of the platform/lifecycle, we only source from the env var if the buildpack api >= 0.8.