Dependency mappings

[fg-j]

Summary

Adds the ability to look for dependency mappings in bindings. Notably, doesn't change the interface of the postal Service to avoid disrupting existing buildpacks. The interface will likely change once we fully implement Service Bindings support.

Resolves #106

Use Cases

Checklist

• I have viewed, signed, and submitted the Contributor License Agreement.
• I have added an integration test, if necessary.

[ryanmoran]

As this is implemented, DependencyMappingResolver has become part of the public API for postal. Do we have a usecase that justifies exposing it as part of the public API, or should we make it private? If it can be justified as a useful part of the public API, then I'd like to see documentation included in the code like we have for the other public types and functions:

packit/postal/service.go

Lines 36 to 43 in e6b39a5

	// Resolve will pick the best matching dependency given a path to a
	// buildpack.toml file, and the id, version, and stack value of a dependency.
	// The version value is treated as a SemVer constraint and will pick the
	// version that matches that constraint best. If the version is given as
	// "default", the default version for the dependency with the given id will be
	// used. If there is no default version for that dependency, a wildcard
	// constraint will be used.
	func (s Service) Resolve(path, id, version, stack string) (Dependency, error) {

[ryanmoran]

@fg-j @ForestEckhardt Can you rebase this off main? I am getting conflicts that I cannot resolve by just clicking a button.

[ryanmoran]

I don't know what happened in the original rebase, but this ended up weirdly including draft and jam update-builder commits that clearly didn't belong to this PR. I've dropped those commits so its a bit more clear what this PR includes and the history looks more reasonable.