Easier navigation in the tree view

**Is your feature request related to a problem? Please describe.**
I think the tree view can benefit from some UI/UX improvement. Now, it's tricky to use (apart from the bug #353) even for experienced AiiDA users that also know the nesting structure of AiiDA-QE workflows.

**Describe the solution you'd like**
Here some issues and suggestions:
- outputs of the workflow are above the sub-workchains. This is counterintuitive to me (first you run sub-workflows, then you get results) and confusing because "outputs" is at the same level of the subworkflows. I suggest to
- group all sub-workflows in a group "sub-workflows" (similar to "outputs")
- put the sub-workflows *before* the outputs
- (this is probably already the case, but to check and guarantee) make sure that subworkflows are shown in chronological order of submission
- See if we can reduce the "AiiDA/AiiDA-QE" lingo. I think the app should be mainly used by non-AiiDA users (but AiiDA users should understand what is going on - so AiiDA lingo can be kept but e.g. in parentheses). Make sure that the main labels are obvious to a reader that knows QE (or maybe even not, just DFT). An example: Now the string says "PwBandsWorkChain<249> Finished [0] [7:results]".
- There is a lot of technical information (maybe not all is needed? e.g. `[7:results]` is probably never needed? I'm not even sure what it means, probably the last step that runs? At least not useful once it finished? (in the title, maybe you can keep it in some internal subcategory, e.g. as you have outputs and subworkflows, you can have "AiiDA details" and put all in it).
- Maybe the status is OK to keep - it might be good to rediscuss the exact string by looking at an example with a non-zero error code, so it's obvious what `[0]` (or any other number) means. E.g. one could write "Finished successfully" if the exit code is 0, "Exited with error code SOME_NAME (401)" if it's not zero, etc. (for every exit state I would have some intuitive string - possibly falling back to the current string if e.g. we forget to implement some mapping for some exit states, so the app does not crash)
- Probably it's OK to keep the PK. However, we should homogenize everywhere how we identify the PK. E.g., here it's , but in the dropdown to list run workflows it's without angular brackets, in the results it's `(pk: NNN)`, in the AiiDA database structure selection is `PK: NNN` etc. (probalby my suggestion is to use always `PK: NNN`, possibly in brackets e.g. here.
- We are indicating the name of the workflow, but this is typically not intuitive (even I, who should know, took almost a minute to figure out that I should have looked into the `PwBandsWorkChain` to look for the SCF output... Intuitively, the bands is a different pw.x step). I suggest to have some more intuitive name associated to each workflow class, and keep the workflow class in parentheses. I think it's easy to have a mapping WorkChain class name -> human-readable string in the app, there are not too many workflows. Again, good to have fallback to just the class name (for instance) if some WorkChain class name is not in the mapping.
- Putting all together, e.g. an example string could be (to be discussed): `DFT (pw.x) main workflow [PwBandsWorkChain, PK: 249] - Finished successfully`, or `PDOS (dos.x) workflow [PdosWorkChain, PK: 281] - Finished successfully` (or e.g. `DFT (pw.x) SCF/relaxation workflow` for the PwRelaxWorkChain?

If you agree, we can provide in a comment below the table of the mapping (class name -> human name), and edit until we are all happy.
In principle, we could also decide to centralize this mapping in the `aiida-qe` package, and then in the app we just use the mapping (even better? so there is higher probability that the mapping is kept updated? or it's more confusing and complex to manage - and if it's used only in the QE app, maybe instead better to keep it here)