Support WithJob inside WithJob

[lanvstn]

Jobs should be able to act as controllers for other jobs. This is currently not possible and explicitly panicked on (due to #3).

I'm thinking a job should be able to open its own Kutest session, even though it already has a Kutest SessID from the controller. In other words, the job controlled by the controller becomes a controller. This should be able to recurse into infinity.

Log propagation challenge.

Currently Kutest relies on the propagation of logs through Kubernetes get log calls. If a job1 schedules job1_1, the logs of job1_1 will be accessible job1 and the logs of job1 on the controller, but we need job1_1 on the controller as well.

A workaround would be to, if we are a controller AND a job, we print the logs of our jobs to our output instead of including it in the report. But that is clunky and not good for those flashy reports.

By design we are unfortunately limited to the k8s API and I'm not to keen on serializing+deserializing Ginkgo reports through the k8s logging channel.

Seems like for a perfect solution a compromise may have to be made on the simplicity on Kutest, but I don't like doing that so it requires some further thought.