Add saucectl imagerunner logs command

[mhan83]

Proposed changes

Add saucectl imagerunner logs <runID> command to fetch the logs for a hosted test orchestration run.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)

Checklist

• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• I have updated the json schema (if appropriate)

Further comments

Still a little uncertain about whether to have the imagerunner subcommand or not. If one day we want to have a logs command for non-HTO resources and we don't mind that saucectl logs overlaps with saucectl imagerunner logs for HTO runs, then I prefer scoping the command with the explicit imagerunner subcommand. If we want to avoid overlapping functionality, then I think we should just go with saucectl logs.

[alexplischke]

Still a little uncertain about whether to have the hto subcommand or not.

Same.

@KunalJain Just going to lay out an overview:

If we namespace this one, but not artifact downloads, then we'll have:

• saucectl artifacts download [...]
• saucectl hto logs [...]

Consequences

• Inconsistent

If we don't namespace:

• saucectl artifacts download [...]
• saucectl logs [...]

Consequences

• The commands have to query a bunch of systems to figure out what this ID you passed in means, which product it belongs to.
• User has only one interface to deal with.

If we namespace both:

• saucectl artifacts download [...] for non-HTO
• saucectl hto artifacts download [...]
• saucectl hto logs [...]

Consequences

• Inconsistent.
• Consistency can be introduced later with a major breaking change, but one would have to come up with namespaces for the RDC/VDC API.