Mostly (?) fixes #557

This sticks to having the whole SBOM operate in terms of packages, so that the toplevel element is still a package potentially consisting of several binaries; but there is a SBOM named after every binary, making them much easier to locate.

Why do it this way

So you may be thinking "Eww, gross! Why don't you just make the binary your toplevel element? Why generate a SBOM for the whole package?"

There is a long list of reasons why it is done this way, most of which are weaksauce ("all components are packages with PURLs so it's more consistent", "the per-binary mode isn't special and isn't a source of lots of extra complexity and bugs", etc). The real reason we output a SBOM for the whole package is the SBOMs clobbering each other.

Imagine you have a target that's both a binary and a shared library. The compiled artifacts get different extensions (.exe vs .dll on Windows, nothing vs .so on Linux), etc. However, when you try to emit stuff like debug info for them, the names will clash! Both are myproject.pdb on Windows. If you run into this, Cargo will print a warning but not actually do anything to fix this.

We have to deal with this problem somehow as well.

There are two sources of clobbering:

1. The target with the same name (this is common)
2. The workspace producing e.g. a library and a binary with the same name but coming from different packages (also common), or even binaries with the same name (unlikely)

We easily sidestep (2) by writing the SBOM into each package's directory. Boom, stuff from different packages cannot clash.

We sidestep (1) by emitting the SBOM for the whole package. So the library and binary targets within the same package can clobber each other as much as they like - it's still going to be the exact same file! You don't have to invent a scheme to differentiate between an rlib, a cdylib and an executable that all got built from the same package - you just look up the name of the binary and off you go.

In case you're wondering why don't we just name each SBOM after the final name of the binary, .exe and all: the answer is that we don't know them. cargo metadata does not provide this information. #532 might help with that. But even if that ever happens, that would still be incompatible with the --target=all mode.

You may notice that these things are now named after a variable prefix and no longer fit the standard naming convention. And that is absolutely correct! That's a bug that was present all along for --output-pattern=package and that we inherited in this PR too. I think there needs to be a .cdx in there when it's not bom.{xml,json}. That is a change in user-visible behavior so that'll require shipping a 0.5.0 release. I think this is a necessary fix, I'll make a PR for that once this is merged to avoid conflicts.