[plan-build] Add Scaffolding direct deps as direct build deps for Plans.
[plan-build] Add Scaffolding direct deps as direct build deps for Plans.

This change aims to fulfill a design goal of Scaffolding: within reason,
a Plan author should be able to do what a Scaffolding package provides
directly in their `plan.sh`. A secondary design goal is that Scaffolding
package authors should not need to call any internal API functions from
the build program. The latter goal surfaced a design issue in the
previous Scaffolding implementation around direct vs. transistive
dependencies.

There are several helper functions that a Plan author (and therefore
Scaffolding package author) may use that are marked as part of the
public API. For example, the `pkg_path_for()` will return the absolute
path to the pkg_prefix for a given dependency. The implementation for
`pkg_path_for()` (correctly) only looks at **direct** build and run
dependencies--not indirect/transitive dependencies. If a Plan author is
using a Ruby Scaffolding package that pulls in Bundler for build-time
dependency resolution, then there is a good change they would want to
call something like: `pkg_path_for core/bundler`. The problem here, is
that the previous implemenation would fail the `pkg_path_for()` call and
report that the `core/bundler` dependency is not a direct run or build
dependency.

This change injects the Scaffolding pacakge into the direct build
dependency array `${pkg_build_deps[@]}` as before, but now also adds
each direct run dependency for the Scaffolding package into the direct
**build** dependency array of the Plan. For example, a Ruby Scaffolding
package that pulls Bundler in as its run dependency, would yield a Plan
`${pkg_build_deps[@]}` array which contained `core/ruby` as well as
`core/bundler/1.13.7/20170104000124`. Note that these Scaffolding
dependencies are full qualified in order for the same exact versions of
Scaffolding dependencies to be captured as Plan build dependencies.

Finally, as the number of dependency resolving functions has grown, the
activity of resolving dependencies is captured in the
`_resolve_dependencies()` internal function to be used in the main
program flow.

Signed-off-by: Fletcher Nichol <77a0fd9e8048bbacd11af4e957bc6ff03b549f49@nichol.ca>

georgemarshall/habitat,rsertelon/habitat,nathenharvey/habitat,georgemarshall/habitat,georgemarshall/habitat,rsertelon/habitat,rsertelon/habitat,nathenharvey/habitat,habitat-sh/habitat,rsertelon/habitat,nathenharvey/habitat,habitat-sh/habitat,habitat-sh/habitat,habitat-sh/habitat,rsertelon/habitat,georgemarshall/habitat,nathenharvey/habitat,rsertelon/habitat,georgemarshall/habitat,rsertelon/habitat,habitat-sh/habitat,nathenharvey/habitat,habitat-sh/habitat,habitat-sh/habitat,nathenharvey/habitat,georgemarshall/habitat,georgemarshall/habitat,georgemarshall/habitat,habitat-sh/habitat