return reporting data from octoherd script

[travi]

#220 (comment) highlighted that, even though i'd test-driven the extraction, i failed to properly await the async script called while looping through the list of repositories. this is a difficult detail to drive based on a test when the called function produces side effects rather than output.

this made me think about how it was too bad that we couldnt count on output from the script since that would enable a test to verify the output, which would highlight the difference in behavior between executing a sync script vs an async script. since we've already discussed reports a bit, this thought led me to wonder if it might make sense to define a convention to return results data from the script related to the reporting goals. runScriptAgainstRepositories could then build a map of the results returned from each iteration of executing the script, indexed by repository (id?/full_name?). then that data could be returned to the caller, so handling of the report could be done based on the raw data in whatever means makes sense for the caller's context. if the caller is the octoherd cli, loadRepositoriesAndRunScript could then leverage any custom bits of the octoherd version of octokit, while not preventing other callers that use just a core compatible octokit instance from also doing some level of reporting.

i dont know if this sort of approach would cover all of the intended goals of what @gr2m had in mind for reporting, but wanted to put the idea out here to see how far it would deviate. if we see this as valuable and as accomplishing enough of the reporting goal, i'm wondering if this is worth including in the work of #221, or if this becomes a follow-up effort afterward.

[travi]

i put #223 together to give a concrete example of what this could look like