Improve Test Loop Status Data Gathering

[AntsInMyEy3sJohnson]

Context

• Package api exposes an endpoint, /status, external actors can use to query the status of the various test loops that are currently being run (total number of runs, number of runs already completed etc.)
• Test loop status currently represented as a struct type in the api package itself

Problem

• According to the Tell, Don't Ask software engineering guideline, the behavior described above is fine -- the test loops inform or "tell" the api package about their status rather than the latter querying, or "asking", for it
• But: The fact that the test loop status is represented as a struct type in the api package means the latter embodies a lot of knowledge about how the status of a test loop has to look like -- something that only the test loops themselves should have to worry about
• This creates unnecessary coupling between the api package and the test loops (map test loop and queue test loop)

Solution

Two options:

1. In api package, represent test loop status simply as map[string]interface{}. Offer function the test loops can invoke to update the state this map holds. Upside: Tell, Don't Ask guideline adhered to. Downside: Test loops have to know how to update the map, thus they have to have knowledge about what it contains and what its structure is -- knowledge they should not need to have.
2. Keep test loop status internal to the test loops. Offer function the api/endpoints.go code can call that represents the status as map[string]interface{}. Upside: Function would act as a "coupling breaker" between test loops and api -- the former could use their internal status representation, and the latter could query a map view thereof, so each component encapsulates only the knowledge it needs to operate on its own data structures. Downside: Violation of Tell, Don't Ask.

So this is really about playing around with these two options and see which one turns out to be more satisfying.