Describe multiple SBOM scan targets

[wagoodman]

What would you like to be added:
Be able to specify multiple targets that where one or more SBOMs are created. Take the following examples for illustrative purposes:

# syft.yaml

inputs:
- type: image
  id: my-image-sbom
  value: docker.io/me/my-image:latest
  format: spdxjson
  
- type: directory
  id: my-source-sbom
  value: ./src
  format: spdx

This would allow for scanning an artifact and source and produce two different sboms, such that in CI invocation would simply be:

# syft.yaml is automatically assumed...
syft
# ...output "my-image-sbom.json" and "my-source-sbom.spdx" files

You could combine the output from multiple cataloging efforts into the same SBOM by using the same id for each input:

# syft.yaml

inputs:
- type: image
  id: my-sbom
  root-package: container
  value: docker.io/me/my-image:latest
  format: spdxjson
  
- type: directory
  root-package: source
  id: my-sbom
  value: ./src

Where the result would be a single my-sbom.json in the spdxjson output. Additionally, anything found in the container will have a relationship tied to a phantom "container" package and anything in the source scanning would have a relationship to a phantom "source" package.

I'm not 100% in love with the proposed format above as it would be easy to abuse when it comes to combining incompatible formats, but it suits for illustrative purposes.

We could surface a small set of this functionality via the CLI by allowing for multiple scan targets:

syft  dir:./  image:docker.io/me/my-image:latest -o spdxjson

Why is this needed:
For more complicated workflows it would be ideal to encode what needs to be cataloged into a description instead of relying on the consumer to orchestrate multiple syft calls with bash.

Additionally there is no way to deal with "multiple" SBOMs with syft, or grouping related items with relationships, which could be a powerful pattern.

[wagoodman]

Another approach to the output here would be to allow for syft to take multiple images as input or a multi-arch image as input and stream multiple SBOM documents to the file in question. How this could for for each format:

• table: simply output multiple tables, with an additional header to list which image is being processed
• json, spdx-json, cyclonedx-json: require single line output, treat the document as JSONLs
• spdx-tag-value: not supported
• cyclonedx-xml: xml already already supports multiple embedded tags in a single doc

This dodges the problem of needing to solve how multiple sources are handled in a single SBOM, and instead this can be handled in something that intentionally takes multiple SBOMs for merging (for example syft merge sbom1.json sbom2.json).

This impacts #617 #3562 #562