Add documentation about test structure.

[wearhere]

The current documentation does a pretty decent job of describing what test cases can do: use SLElements to manipulate the UI; use app hooks to manipulate the app.

What we're lacking is guidance as to how tests can and maybe ought to be structured, things like:

• Elements used by multiple cases can be test ivars.
• Don't put tear-down work after assertions, lest they fail and the work be skipped--it should go in -tearDownTest or -tearDownTestCaseWithSelector:.
• Use abstract classes to consolidate set-up and tear-down work.
• Make tests handle their own set-up and tear-down, so they can be run independently (i.e. by focusing) and to flush out test pollution.
• It may not be possible to tear-down/undo some changes using the UI, but that's what app hooks are for (read: how to avoid ordering your tests).