Pass the sub-component as a parameter in enter_component(), as it's needed in the C++
implementation, it's readily available (no need to unwrap again) and Rust will need it, too.
For the following reduced test-case the order in how the dynamic nodes
in the item tree were generated (and dyn indices assigned) differed from
the way the visit_dynamic_children slots were generated:
```
Blah := Rectangle {
for x in 1: Text {
text: "Should be on the right";
}
}
MainWindow := Window {
width: 772px;
height: 504px;
Text {
if (false): TouchArea {
}
}
Blah {
x: 200px;
}
}
```
The item tree node was constructed using build_item_tree, which
basically assigned dyn index 0 to the "repater" for the touch area
and "1" to the one for the repeater inside the sub-component.
Afterwards we traversed the element tree - without descending into the
sub-components - to generate the fields and the dispatch in in the
dynamic visitor. Here a subtle order would result in a mismatch of
indices:
recurse_elem_level_order would end up visiting Text, Blah and then
Text's children, assigning the first dynamic index to Blah.
This is now fixed by merging the two iterations into one.
focus() is implemented by calling set_focus() on the window with the absolute item
index as a parameter. The
generate_item_indices pass generates local item indicies,
which need to made absolute.
Sadly there exists a gap in the item tree between the root element of a sub-component
and its children. Therefore each sub-component gets two members passed to the constructor,
the tree_index and tree_index_of_first_child.
The former is to be used when the local index is zero (indicates the root).
The latter is used as base for any children.
In a tree like this:
```
SubCompo := Rectangle { Image {} }
MainCompo := Window {
TouchArea {}
SubCompo {}
Text {
Path {}
}
}
```
The path element would have a local item index of 4, which is wrong. Right before the path
there would be the child(ren) of the sub-component, which
were not accounted for.
There's a check that verifies that the relative item indices match, between what
the item tree building code in the generator sees and the generate_item_indices pass.
The counting of the relative indices was incorrect with regards to the sub-trees.
For the item index generation and the member population for the C++
structs, a level-order variant of `recurse_elem` is sufficient - as also
indicate by the unused item index parameters.
