When skipping bodies in library code, we lose the information whether a
body was originally present. This can be important, for example when
determining whether a trait method has a default implementation.
With this change that information can be recovered via the
`hasImplementation` predicate.
This is a small devex improvement to the rust code generator.
Usage of `sorted` in `rustgen.py` was causing the generated code to be
completely reshuffled on renames, which made diffs hard to follow. As an
example see [this generated file diff](https://github.com/github/codeql/pull/19059/files#diff-c938ba77a3398dd4c633ada5702a03477705c24740a2f7d1e40d4b270d8c3f86).
This will make the order deterministically based on the order of
definitions in the schema file. This means that renames will find the
same place in the generated file, and the place in the generated file
will generally be more predictable with respect to the schema.
However, that does mean this change is heavily reshuffling the generated
code.
This works around a quirk in rust-analyzer's AST generation machinery,
where for an `<X as Y>` path there might be no way to directly get `Y`
from the path segment.
This splits the `ArrayExpr` class into `ArrayListExpr` and `ArrayRepeatExpr`.
This uses the `synth.from_class` machinery to integrate seamlessly into the
generated code, by hiding the extracted `ArrayExpr` behind an internal class
and replacing it with a hierarchy of those two classes under a new
`ArrayExpr` class.
This doesn't require `ql.name` and is simpler while we don't have
to write upgrade scripts. The `ql.name` mechanism might get useful
once we do have to write upgrade scripts, as that doesn't change the
dbscheme.