Define the portable sbom contract, without a generator

[mxwlf]

Documentation only. Adds a sbom convention under Extending make ci for your
project, and deliberately ships no generator.

The split

Portable — the contract	Project-specific — the implementation
A sbom target, in the ci chain, after whatever builds	The generator and its toolchain
Output under the same gitignored artifacts directory as the other reports	The dependency-manifest path it reads
Published by the CI stubs beside test and coverage reports	The SBOM's subject name and version

Why no generator here

An SBOM's substance is the resolved dependency graph, and that graph only exists
inside an ecosystem's resolver — NuGet's project.assets.json, a package-lock.json,
a populated virtualenv. Anything repo-level either shells out to those resolvers
anyway or parses manifests and guesses, and guessing gets transitive and
conditionally-referenced packages wrong.

There is also a concrete objection specific to this template: the obvious generator is
a .NET tool, and standardising on it would drag the .NET SDK into the Requirements list
for every non-.NET project created from here.

And this repository ships no artifact. Its only dependencies are pre-commit and the
rev-pinned hook repos — a developer toolchain nobody deploys — so an SBOM of it would
inventory something that is never shipped. Documenting the seam is the useful thing;
filling it is not.

Also recorded

• Generate from the build output, not the source tree.
• A per-pull-request SBOM and a release SBOM are different artifacts: the first is a
  drift detector, the second describes a released artifact and wants attaching and
  attesting.

dotnet-template implements this contract for .NET (SPDX 2.2 via Microsoft's
sbom-tool) and is linked as a worked example.