LAVA results to nodes parsing

At the moment i am observing inconsistencies in LAVA parsing. For example:
https://staging.kernelci.org:9000/viewer?node_id=65e90b91f7f28490bc58a8f4

This LAVA job clearly fails to execute test suite named " case: 1_kselftest-dt", but it is not represented in node.

As remark, @hardboprobot also suggested to introduce kind: job for nodes, which doesn't represent test results.

I think we need to define clearly what should be in nodes. For example, what i expect to see:

https://lava.collabora.dev/scheduler/job/12973057

```
root node - lava job, kind job, result: pass, for job 12973057
child nodes first level - whoever have parent by "definition: lava", which might be test-suite but also might be just some action, but failure of such might indicate regression (for example failed login-action due some kernel issue).
child nodes second level, for example all nodes of case "0_tast" with tast tests results.
```

More data extracts:

case: login-action
case_id: 464309677
definition: lava
duration: 13.84
extra: ...
level: 2.2.5.1
namespace: modules
result: pass

case: login-action
case_id: 464309677
definition: lava
duration: 8.02
extra: ...
level: 5.2.5.1
namespace: chromeos
result: pass

Then test which part of testsuite _tast

case: video.ChromeStackDecoder.vp9_show_existing_frame
case_id: 464309942
definition: 0_tast
endtc: 18475
result: skip
starttc: 18475

And then result for test suite

case: 0_tast
case_id: 464309943
definition: lava
duration: 28.36
namespace: chromeos
path: inline/cros-tast.yaml
metadata: {'format': 'Lava-Test Test Definition 1.0', 'name': 'cros-tast'}
run: {'steps': ['cd /home/cros', 'lava-test-case tast-tarball --shell curl -s https://storage.chromeos.kernelci.org/images/rootfs/chromeos/chromiumos-skyrim/20240129.0/amd64/tast.tgz \\| tar xzvf - && cp remote_test_runner /usr/bin/remote_test_runner && mkdir -p /usr/libexec/tast/bundles/remote/ && cp cros /usr/libexec/tast/bundles/remote/', 'while ! ping -c 1 -w 1 $(lava-target-ip); do sleep 1; done', 'lava-test-case os-release --shell ./ssh_retry.sh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i /home/cros/.ssh/id_rsa root@$(lava-target-ip) cat /etc/os-release', './tast_parser.py video.ChromeStackDecoder.*', './ssh_retry.sh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i /home/cros/.ssh/id_rsa root@$(lava-target-ip) sync && poweroff && exit 0']}
result: pass
revision: unspecified
uuid: 12973057_6.2.3.1

-------
Another example:

https://lava.collabora.dev/scheduler/job/12973654

```
root node - lava job, kind job, result: pass, for job 12973654
child nodes first level - whoever have parent by "definition: lava", again...
child nodes second level, for example all nodes of case "1_kselftest-alsa" with tast tests results. (who have "definition: 1_kselftest-alsa")
```

Separate test case, which has (parent?) definition: 1_kselftest-alsa

case: alsa_mixer-test
case_id: 464337017
definition: 1_kselftest-alsa
endtc: 3065
result: pass
starttc: 3065

And this is test suite 1_kselftest-alsa:

case: 1_kselftest-alsa
case_id: 464337018
commit_id: e80ad888d53e668c81b9ca78f92b6a5aa0369d90
definition: lava
duration: 13.10
namespace: common
path: automated/linux/kselftest/kselftest.yaml
repository: https://github.com/kernelci/test-definitions.git
result: pass
revision: staging.kernelci.org
uuid: 12973654_1.5.2.3.5

I will search more examples, for example lava jobs with kernel panic.

Start by comparing the current node output with the LAVA job examples linked in the issue, including jobs 12973057 and 12973654. Define the intended hierarchy for jobs, LAVA actions, test suites, and test cases, including how failures are represented; done means the reported nodes consistently reflect those relationships and results.

Written by the indexing model from the issue text.