[Feature] Create checklist for verifying new or modified UI elements

This checklist will create a streamlined and repeatable process for testing and also prevent things from slipping through the cracks during code review, such as the help text for verifying deployments added in #44.

Things to include:
- All required components for a new UI element such as a databound setter, getter, `doCheck...` method, corresponding help text, i18n compatibility for the title and help text, etc.
- Spelling out (in a human readable form) the considered scenarios for user input and expected verification message in that scenario.
- Spelling out what it means when the feature is working and what expected outcomes correspond to the user's input. (i.e. will the timeout be accurate? Will it finish early if in a successful or unrecoverable state?)
- etc...

While it should be the responsibility of the person submitting a change to verify it through testing, having a basic checklist with the addition of submitter-provided explanations for how to check the change makes it easier for someone else to take a second look and verify in a fresh environment/configuration.

No file, test, or entry point is named in the issue. Review the repository's documentation and contribution conventions, then define a checklist covering required UI components, i18n and help text, input scenarios, verification messages, and expected outcomes.

Written by the indexing model from the issue text.