Add additional_buildpack_binary_path macro

[Malax]

Follow-up to: #314

Resolves the path to an additional buildpack binary by Cargo target name when the buildpack is packaged with libcnb-cargo or libcnb-test.

This can be used to copy additional binaries to layers or use them for exec.d. To add an additional binary to a buildpack, add a new file with a main function to bin/. Cargo will automatically configure it as a binary target with the name of file.

Note: This only works properly if the buildpack is packaged with libcnb-cargo/libcnb-test.

Implementation notes:

This follows the pattern for the existing proc macro where the proc macro itself only concerns itself with the logic that strictly requires a proc macro. In this case, verifying that the given binary target name is valid. Additional logic is implemented in a regular macro (here: additional_buildpack_binary_path).

Strictly speaking, the macro should live in libcnb-cargo as it only works when a buildpack is packaged with libcnb-cargo. However, since libcnb-cargo already is a library for implementing packaging, adding a dependency to it from an actual buildpack seemed weird. It also would would hinder discoverability. Therefore, I decided to add it to libcnb proper.

I'm slightly unhappy with the hardcoding of the path to the additional-bin directory in libcnb. I considered adding shared code between libcnb-cargo and libcnb that concerns itself with the construction of that path. To make that work, we would've needed to create a new shared crate to avoid circular dependencies (i.e. libcnb-common). For now, this seems to be overkill but should be reconsidered when we have more use-cases for a shared crate.

Closes GUS-W-10695287

[edmorley]

I'm slightly unhappy with the hardcoding of the path to the additional-bin directory in libcnb. I considered adding shared code between libcnb-cargo and libcnb that concerns itself with the construction of that path.

This seems fine to me for now, since:

• We'll at least have integration tests post (Draft) - Add exec.d Support #311, that ensure the two constants are in sync.
• Even if we did split this shared code out, it wouldn't prevent issues with the values being changed in the future, since for example if a buildpack hadn't yet updated its dependency on libcnb, but pulled in latest libcnb-cargo (where the path had been changed), then they would see breakage (unless libcnb-cargo eventually has an allowlist of supported libcnb framework versions etc). As such, we'll need to think carefully should we ever change the path in the future anyway, so hardcoded vs shared code in separate crate doesn't really buy us much.

[edmorley]

Should we add a comment here and in libcnb-cargo about keeping these path constants in sync?

[Malax]

I think it's quite obvious that these need to be in sync when you come across this code. 🤔