Determine strategy for encoding test plugin methods

Brian's proposal describes test plugins as

> Python objects that conform to the Test Plugin interface and are used to execute a given test. They can be extremely simple or quite complex but, ultimately, they provide a very basic interface to the Orchestrator that’s calling them.

This "interface" would include methods to `run()`, `get_status()` [of], and `cancel()` a plugin. Figuring out how to specify these methods via REST requests is a subject for later...

For now, we need to figure out the most sensible way to structure a `Plugin` class and any related modules/classes such that the functionality is fairly flexible and extensible.

Start by reviewing Brian's proposal and the repository's existing structure for test plugins; the issue names no files, tests, or entry points. Define how a Plugin class should expose run(), get_status(), and cancel(), and document the chosen extensible structure and how it could later support REST requests.

Written by the indexing model from the issue text.