Support dependency mappings

[ryanmoran]

Context

RFC-0010 has been accepted and so we should enable packit to support this feature for our buildpacks.

Proposal

We could extend the functionality of the postal package to support looking up dependency mappings if there are dependency-mapping bindings available from the platform.

[arjun024]

Related issue: #107

[sophiewigmore]

Possibly helpful context from looking into this:

Documentation on bindings on paketo.io is very helpful.
Notably:
Bindings set at build-time located: /platform/bindings
Bindings set at runtime located: $SERVICE_BINDING_ROOT or $CNB_BINDINGS

Libcnb does binding lookup here.

It might be helpful to emit logs that let the user know we are using the user-provided service bindings rather than the buildpack.toml default.

Tested out changes to packit that work bindings with by doing the following:

1. Made a temp directory called binding
2. Inside, I created a file called type that contains dependency-mapping
3. Created a file with the SHA256 of a dependency from the buildpack.toml, and the URI from the buildpack.toml. This follows the directory structure outlined in the Kubernetes spec example in the RFC.
4. Ran pack build with the --volume /tmp/binding/:/platform/bindings/my-binding and a local version of the buildpack that pulls in the version of packit with binding changes

[fg-j]

Given this RFC, it seems that the CNB-specific spec for bindings has been deprecated. @paketo-buildpacks/tooling-maintainers should we implement support for both specs, or just the Kubernetes Binding Spec?

[sophiewigmore]

@fg-j I believe we said in a meeting at some point we wanted to follow the Kubernetes Binding Spec. Double check with @ryanmoran