refactor(semantic,linter): assert that Program is always the first node

[ulrichstark]

Follow on to #12087

We might be able to improve perf of AstNodes::ancestor_ids a little by using a custom iterator, instead of std::iter::successors.
Also, node_id == NodeId::DUMMY would be a cheaper check than parent_id == node_id. The NodeId of Program in practice is always NodeId::DUMMY (0), but we don't have a static guarantee of that at present. But we could get that guarantee by adding assert!(self.parent_ids.is_empty()) to the top of AstNodes::add_program_node (or maybe just debug_assert!).
@overlookmotel in #12087 (comment)

My changes:

• added constant NodeId::ROOT (same value as NodeId::DUMMY, but leads to more intuitive code)
• added asserts in add_program_node that nodes are empty and node kind that's being added is Program
• ancestor_kinds and ancestors now build upon ancestor_ids, making std::iter::successors implementation obsolete
• make AstNodeParentIter simpler by iterating over node ids and by making use of previous assertions of add_program_node
• remove root, root_node and root_node_mut functions and replace their use with either new program function or NodeId::ROOT

Results in general much less code, especially less boilerplate code in the linter around getting the program node. Also might hopefully yield some small benchmark improvements.

Edit:
Only very minor if not zero improvements on the linter benchmarks :(

I also noticed while working on this that the ancestor iterator methods where documented as "The first node produced by this iterator is the first parent of the node pointed to by node_id". That statement was incorrect because all the iterators didn't yield the parent of node_id, but node_id itself as first item. I updated the documentation of these methods to correctly reflect their implementation.

[codspeed-hq]

CodSpeed Instrumentation Performance Report

Merging #12123 will not alter performance

_{Comparing ulrichstark:assert-that-program-node-is-always-first-node (ae98c1c) with main (e8e2a25)}

Summary

✅ 34 untouched benchmarks

[graphite-app]

Merge activity

• Jul 8, 2:03 AM UTC: @ulrichstark we removed the merge queue label because we could not find a Graphite account associated with your GitHub profile.

You must have a Graphite account in order to use the merge queue. Create an account and try again using this link