nonspec: new website build strategy

[zachariahcox]

This PR focuses on what the flow would look like after we have a late branch model.

Depends on #1328 where all the devcontiner and late-branching pieces will need to be settled first.

This PR is almost entirely file moves.
It demonstrates what a world would look like if there was only one copy of the spec in a branch and how a www folder + deployment process could be created to flatten versions of the spec from other branches.

Ultimately, it would be nice to store those spec versions in releases and not rely on git shenanigans.
We'd need to settle on a release strategy for that, which is Its Own Discussion 😂

Critical file changes include:

• www/combine-versions.sh
• netlify.toml
• .gitignore
• proposed release automation? .github/workflows/publish-spec.yml: Added a GitHub Actions workflow to publish the SLSA specification as a release. This workflow triggers on pushes to release branches, creates a zip archive of the spec, generates a build provenance attestation, and uploads both as release assets.

[netlify]

❌ Deploy Preview for slsa failed.

Name	Link
🔨 Latest commit	ef10969
🔍 Latest deploy log	https://app.netlify.com/sites/slsa/deploys/68050350503a120008314ec4

[Copilot]

Pull Request Overview

This PR demonstrates a new website build strategy by reorganizing the repository structure and introducing a GitHub Actions workflow to automate the publishing of the SLSA specification as a release.

• Adds a new workflow (.github/workflows/publish-spec.yml) for release automation that creates a zipped archive of the spec, generates a build provenance attestation, and attaches both to the release.
• Introduces file moves and minor adjustments to support the single-copy spec and deployment process.

Files not reviewed (1)

• .devcontainer/devcontainer.json: Language not supported

[lehors]

Thanks for doing this. I like it. Just some thoughts that came up as I went through this a first time:

What's the reason to change from docs/ to www/ ? It's no big deal but this creating a lot of noise in this PR.

We'll also need to document what steps need to be taken when releasing a new spec (something that's missing today!) One will still need to update files like _data/versions.yml _data/nav/* _redirects among others. Experience with the release of v1.1 just showed that there are quite few bits and pieces all over the place that need updating. We shouldn't need to find those the hard way every time.

We should aim to eventually have combine-versions.sh pull in the list of specs to deploy from one of the config files - I think _data/versions.yml.

Just to be clear: I'm not asking for any of the above to be part of this PR! :-)