Reword to clarify streams lacking a version number

[eli-schwartz]

See #41 for discussion. Here's my attempt at solving the wording, hopefully even in a manner that technically means the same thing.

[bonzini]

I think this is too complex and, at the same time, doesn't clarify whether:

• new features in TAP14 (such as subtests) should be accepted or rejected if the TAP version line denotes an older version or is missing

• parsers for TAP14 should reject TAP version 15 or not.

[isaacs]

Suggested language (from #41, added forward-looking language as well). I think this leaves us all in the clear as far as our current parsing behavior, doesn't impose any additional burdens on new entrants or significant changes to the semantics, and still leaves the door open for harness implementations that want to be a bit more strict about the versions they support.

---

To indicate that test output is TAP13 or newer the first line SHOULD be

TAP version <major version number>

If the first line of the input is not a version line, harnesses MUST behave as if a TAP version 12 line was present.

Harnesses MAY require a minimal version and reject any input that specifies an older version. Harnesses MUST NOT treat a TAP stream lacking a version line as a failed test, unless they do not support TAP version 12 input.

Harnesses MAY interpret ostensibly TAP13 or TAP12 streams (including those lacking an explicit version) as TAP14, as this specification is compatible with observed behavior of existing TAP13 consumers and producers. For example, a Harness MAY parse child tests that appear in an unversioned TAP stream.

Harnesses MAY emit a warning or failure when encountering a version declaration greater than 14. However, as ongoing backward compatibility is expected in future versions of the TAP specification, Harnesses SHOULD attempt to parse a higher-versioned stream as faithfully as possible.