Minor changes to remove the notion that this is a "proposal" and instead
just describe SLSA as it is.

Also explain that levels 2-3 are likely to change in the future, rather
than using some sort of symbol (*) or term (provisional), since
technically all requirements are subject to change. It's just that 2-3
are more likely to change.

Changes to requirements:
- Remove "Source Integrity", add immutable references to "Hermetic".
- Drop "Common" from SLSA 2 because it is likely expensive.

Clarifications:
- Split out "Ephemeral Environment" from "Isolation" (from #52).
- Explain that GH-generated merge commits meet Verified History (from #52).
- Clarify that all artifact references are immutable (from #52).
- Rename "Dependencies" to "Dependencies Complete" to avoid confusion.
- Define "SLSA level", "provenance", and "top-level source."
- Other minor cleanups.

- Make the vision diagrams consistent with the terminology section:
  - Output is on the right, input is on the left.
  - Use colors consistently.
  - Rename "resource" to "artifact locator".
  - Simplify the diagram to reduce confusion (fixes #31).
- Update the level explanations based on recent changes:
  - SLSA 1 is unsigned.
  - Add SLSA 1.5 (merged with the SLSA 2 section).
  - Minor wording updates.
- Remove Deployment Policies section. We will eventually need to explain
  policies, but for now let's omit it until we agree on what that should
  look like.

Previously, we differentiated between Resources and Artifacts, and SLSA
was a property of a Resource's security policy. However, many readers
found this concept very confusing.

Now, SLSA is purely a property of the artifact. If provenance exists
showing that it met the requirements, the artifact meets the level. No
policy or notion of "resource" is required. This simplifies the model at
some cost of security, which we have collectively decided is worth the
trade-off.

NOTE: The Vision section will be updated in a future change.

This makes the table easier to read since one box is not a simple
checkmark instead of a word.

This reads better and is consistent with the new provenance
requirements, which all use adjectives.

Example: Isolation -> Isolated.

Add a new level, SLSA 1.5, between 1 and 2. We will renumber all the
levels to integers right before we finalize the first version. In the
meantime, we keep numbering the same to reduce confusion.

Split Tamper Resistant into Authenticated + Service Generated +
Non-Falsifiable. This split makes the meaning more clear, particularly
that SLSA 1 is unauthenticated. SLSA 1.5 requires only the first two,
with non-falsifiable being a property at SLSA 2.

The PDF is available again.

This reverts commit 85861abf.

SLSA 1 is now fully defined and has lower requirements.

Major changes:

- Replace "Readability" with "Version Control", removed at SLSA 1.
- Add "Build Service", required at SLSA 2.
- Split "Provenance" into three rows, and do not require tamper
  resistance (e.g. signing) until SLSA 2.
- Remove "Enforcement". This is now orthogonal to the level.
- Do not require "Logging", "Policy", or "Common" until SLSA 2.
- Simplify "Policy" to not talk about build entry point.

Minor changes:

- Rename "Change History" to "Verified History".

We can use tags to indicate prior versions, instead of listing it
directly in the doc.

Add a reminder to the reader that this is stil in flux, replacing the
old reminder about community feedback.

"Standard attestation format" should link to https://github.com/in-toto/attestation not a pull request.

Looks like Google took down the free copy of the book, so we just have
to link to the landing page. That also means we can't use that as one of
our "benefits of reproducible builds" links. :-(

Closes issue #9.

- Better explain the difference between "reproducible" and "verified
  reproducible".
- Clarify that reproducible is required unless there is a justification.

Previously we only "recommended" reproducibility. This was both very
weak and also unenforceable.

Now we require Reproducibility unless there is a justification why it is
not. This is a much stronger motivation to make things Reproducible: it
is the path of least resistance. Furthermore, this can now be checked
in an automated way: either the "reproducible" bit is set or the
"justification" is non-empty. We will likely want to have an enum of
valid justifications, but that will be decided once we write detailed
builder requirements.

At SLSA 3, we now recommend reproducible builds. This is not a strict
requirement because not all builds can become reproducible, as explained
in the text. Once we write the detailed requirements, we will likely
want to somehow explain that reproducible should be the default, while
still allowing individual projects to opt-out.

The reason for adding this recommendation is to move the industry
towards reproducibility, which is a generally useful property. By having
it as the "default" path, most software will just go with the past of
least resistance rather than opting out.

Note that this does not require *verifying* the reproduction for
security. Instead, the builder just claims that it was reproducible,
presumably by building it twice and making sure that the output is
identical.

Fixes #14.

Fixes #12.

* Replace smart quotes with dumb (ASCII) quotes.
* Make the source to the tables look nicer.
* Fix the legend.
* Increase headers by one, so that # is just for the title.
* Remove style tags that GitHub doesn't parse.
* Rename "Notes" to "Footnotes".