The `ParentChild` tests have been generalized to test all `PrintAst`
by factoring out `PrintAstNode` into a separate file.
The `child.ql` and `parent.ql` tests have been removed as they are
subsumed by `PrintAst.ql`. Also, a new `no_parent_child_loops` is
added to detect back edges to a root node (back edges to a non-root
node are already detected by `no_double_parents.ql`).
* made `members` children of an `IterableDeclContext`
* removed `elements` from the children of `EnumCaseDecl`, as they are
already children of the enclosing `EnumDecl`
* removed `base` from the children of `SelfApplyExpr`, as they currently
are already descendants via `getArgument(0).getExpr()`. We should
maybe consider either removing `base` from the schema and add it as
a shortcut on QL, or finish up replacing all `SelfApplyExpr` instances
with synthesized types.
In order to distinguish overloads of the constructor and for consistency
with other function calls, `ConstructorDecl` string representation uses
the name which includes parentheses and parameter labels.
For consistency also the destructor got the same change, which means
all `DestructorDecl`s will now show as `deinit()` rather than `deinit`.
There was an issue in case multiple inheritance from classes with
children was involved, where indexes would overlap.
The generated code structure has been reshuffled a bit, with
`Impl::getImmediateChildOf<Class>` predicates giving 0-based children
for a given class, including those coming from bases, and the final
`Impl::getImmediateChild` disjuncting the above on final classes only.
This removes the need of `getMaximumChildrenIndex<Class>`, and also
removes the code scanning alerts.
Also, comments were fixed addressing the review.
There were missing extractions from the Builtin (and other) modules.
This was actually caused by two issues:
* we did not visit all required modules, as for example the `Builtin`
module does not appear as being imported by anybody (together with
another mysterious `__Objc` module)
* moreover the `Builtin` module works internally by only creating
declarations on demand, and does not provide a list of its top level
declarations.
The first problem was solved by moving module collection to the actual
visiting. This may mean we extract less modules, as we only extract the
modules we actually use something from (recursively). This change can
be reverted if we feel we need it.
The second one was solved by explicitly listing the builtin symbols
encountered during a normal extraction. This does mean this list needs
to be kept up to date.
