[feature] Expose more information about a job for debugging purposes

[fosterseth]

What I'd like to be able to tell at a glance

1. what was the exact work_submit command that started the work? this would be analogous to the job_args field in awx
2. what ongoing threads/processes/file descriptors are open for a particular work unit?
   • i.e. is monitorRemoteUnit still running? we can't infer that from the status because monitorRemoteStatus and monitorRemoteStdout operate in separate threads
   • is GetResults spinning in a loop

Solutions:

1. Logging data. This could be structured logging, similar to job_lifecycle in awx.
   Pros: doesn't require changes to work unit structs, or to the status file.
   Cons: Finding and parsing logs is tedious and not fun.

2. Put this data in work unit structures. This can either be written to disk or kept just in memory.
   Pros: we can just narrow in on some culprit work unit by looking at its status file or by calling some receptorctl that gives us more information about the work unit
   Cons: more work to implement and get right

[fosterseth]

@AlanCoding maybe you have some other ideas of nice-to-haves when it comes to extra information about a receptor work unit