Describe the architecture and operation of the TCK test harness

The role of the TCK (Technology Compatibility Kit) is to determine whether an implementation (i.e., an AsciiDoc language processor written in any programming language) is compliant with the specification. It will also be used to determine whether the assertions in the specification can be verified.

The purpose of this issue is to describe an architecture for the test harness* that can meet these goals. In other words, how it will it work? How can it be designed so that it can be used by an implementation written in any language? We need to consider both how the assertions are conducted and also how an implementation can adapt to the harness.

If necessary, create separate issues to discuss finer points, such as the schema and format to use for the documented-oriented tests (e.g., an ASG).

* A test harness is the heart of the TCK. It provides both the test execution engine (testing framework) and the test data. To cite Wikipedia, "A test harness should allow specific tests to run, orchestrate a runtime environment, and provide a capability to analyze results." The test harness will likely require implementations to provide an adapter that allows the test harness to execute the implementation code within the lifecycle of the test suite.