Refactor libcnb-cargo

[Malax]

I would've loved to split this PR up a little more. However, one of the main objectives of this PR was to remove
complexity (in the original sense of the word: consisting of many interconnecting parts or elements) that was quite
the challenge. I managed to break out some PRs regardless: #659, #658, #656, #654, #652, #653 (all merged).

Some further refactoring will be done in subsequent PRs to keep this one smaller. See the issues for these:

• Simplify dependency graph implementation #660
• Replace hardcoded buildpack.toml and package.toml strings with constants #661

To ease review, I'd suggest taking a look at the new files in libcnb-package first. They are self-contained and can
be reviewed individually. Then, review libcnb-cargo/src/package/command.rs top to bottom. The diff for that file
isn't very helpful. As the last step, go over the diff of the PR for the filler code.

High Level Overview of Changes

Errors

Split errors into dedicated types where it made sense. Most functions in libcnb-package now have their own error type that implements Display, Debug and Error. Splitting them allows us to build an error hierarchy when needed. For example, packaging a directory as a buildpack can either fail with an error specific to meta-buildpack packaging or
and error when packaging a libcnb.rs buildpack.

This slimmed down the main Error type for libcnb-cargo's package command. Combined with the previous PR that aimed to simplify errors in libncb-cargo (#652), error.rs went from ~250 lines to just 28.

Since Display, Debug and Error moved to the error types, we can re-use these representations outside of
libcnb-cargo. For example, support for testing meta-buildpacks to libcnb-test can re-use the error types and string
representations - less effort implementation wise and error messages are consistent.

If we ever want to add more elaborate error messages to libcnb-cargo, for example adding hints about CLI flags that
are out of scope for the generic string representation, we can still match against the concrete error value we're
interested in and print a different message.

Moving build and packaging logic to libcnb-package

Similarly to #633, this PR moves all packaging and build logic to libcnb-package so that it can be re-used outside
of libcnb-cargo. Functions have been refactored to be less intertwined with others and make fewer assumptions. One
big change is the explicit mapping from buildpack IDs to packaged paths. Earlier, libcnb: URIs where replaced by
"guessing" where the built output should be located. Functions that deal with libcnb: URIs not take an explicit
mapping.

Dependency Graph as Single Source of Truth

The dependency graph of CNBs was previously only used to determine the build order. With this PR, it becomes the single source of truth. As before, at the start of the program, the graph is being built. Afterwards, we query the graph when we need information about the buildpacks in the cargo workspace.

For example, to determine if we only need want to build the buildpack in $CWD, we simply query the graph for a node
that represents a buildpack located at $CWD - no additional validation of the contents of $CWD required.

The dependency graph also now only contains nodes and edges that are relevant to the program. CNBs in the workspace that do not need to (or cannot) be packaged with libcnb-cargo are omitted. Also, dependencies that are not libcnb.rs CNBs in source form are not represented in the graph anymore. This simplifies the code that comes after the building of the dependency graph since no filtering is required after that point.

A module to build this dependency graph has been added to libcnb-package so it can be re-used.

Support for non-libcnb.rs CNBs

Previously, libcnb-cargo had some special cases to support non-libcnb.rs buildpacks. I removed those since they're no longer necessary. libcnb-cargo will now simply leave non-libcnb.rs CNBs untouched but keep references (in
package.toml files) to them. This allows meta-buildpacks with non-libcnb.rs CNBs to continue working as expected
without any special logic inlibcnb-cargo.

The only change for end-users is that those buildpacks will no longer be printed as "being built" by libcnb-cargo.

Removal of BuildpackData<_> and PackageDescriptorData<_>

These wrapper types were basically just PathBuf + BuildpackDescriptor and PackageDescriptor respectively. In many cases the path wasn't used. Functions now only take BuildpackDescriptor and PackageDescriptor and a path if needed. This allows us to remove these wrappers that had their own machinery to read them from disk. Since we already have a generic way of reading TOML files (read_toml_file/write_toml_file) we can now use those instead.

Apart from removing code, the cognitive burden is lessened. I found it hard to wrap my head around these wrappers
since they are special constructs that are only used in the libcnb-cargo context.

Fixes: #638, #599

[Malax]

I'm not sure what to do with the CHANGELOG here, especially when we talk about libcnb-package. It would essentially read: "everything changed, take a look". Ideally, libcnb-package wouldn't be public, but it is. :/

[edmorley]

Thank you!

[edmorley]

I'm not sure what to do with the CHANGELOG here, especially when we talk about libcnb-package. It would essentially read: "everything changed, take a look". Ideally, libcnb-package wouldn't be public, but it is. :/

One option would be for us to update libcnb-package's readme to say something like "this is an internal libcnb implementation detail, API stability guarantees do not apply" - then we can just skip describing changes in the changelog, and only discuss them in terms of whether end-user behaviour of libcnb-{cargo,test} changes?

We could also add something similar to the readme of libcnb-common, and have anything in there that we think end-users will use be re-exported via libcnb instead.