Feat: Make Tasks Addressable by ID and extend available information

[patmagee]

What

This PR is an implementation of the discussion in #204.

• It adds a new model called TaskLog which is distinct from the Log model. The rational here is that having a specific model for task information allows us to put more task oriented data in it. Properties like id and tes_uri are strictly related to tasks, since run_id already is defined in the outer scope of a workflow.
  • I have explicitly chosen to keep the type of task_logs within the RunLog as Array[Log] to prevent any breaking change.
  • This was motivated by the fact that an id MUST be required if we are try rely on it for addressing tasks. Requiring this within the Log attribute did not make sense since it was shared between the workflow and individual tasks. Additionally, forcing a required attribute could break downstream implementations
• Adds a new endpoint for retrieving a task directly. Tasks are addressable now so why not! In a system that has 100s or 1000s of tasks for a given workflow run, this subtle optimization could make life a lot easier
• added a new tes_uri field to allow for interop between tes and wes. This approach does not try to incorperate TES into the WES sep directly but provides an easy and Official mechanism to go between the two. TES is a much more rich view of a task so we should not try to re-implement
• add system_logs properties to Log and TaskLog entities.

Closes #204

[uniqueg]

I've just seen that I noticed the issue with RunStatus vs State before and that it should be fixed with #172 (I will look at that tomorrow). So please ignore that part. I guess it's just important that we merge #172 first and then merge that into this PR before merging.

[patmagee]

Given the timeline for connect and the previous sign off by @wleepang and @uniqueg I am going to go ahead an merge this into develop