SCIP symbols for inherent impl declarations are ambiguous

[mgsloan]

In #18758 the plan is to only include the first SymbolInformation in this case. An alternative might be to number them (and append these numbers using Meta SCIP descriptors), but this is tricky with how static_index.rs is implemented.

Not sure how important this is, since inherent impl declarations are not really referenceable. They do show up in symbol names, though, and some consumers of SCIP might expect to be able to resolve prefixes of SCIP symbols.

[Veykril]

Numbering would be ideal in my eyes. How are trait impls handled, that is if you had a impl Trait<Bar> for Foo and impl Trait<Qux> for Foo?

[mgsloan]

@Veykril The current code is buggy there and those traits would alias each-other, both are Foo#Trait#. With my improvements in #18758, they're instead impl#[Foo][`Trait<Bar>`] and impl#[Foo][`Trait<Qux>`]. I believe this is typically unique, but I suppose it is not in the presence of specialization. However, specialization is unstable and doesn't seem to have a clear path towards stabilization afaict.

I checked, and trait impls cannot be split into multiple declarations the way that inherent impls can, so the numbering does not apply.

To implement numbering I believe this would need to get added to the nodes at parse time. I do not want to figure out how to implement that, and I would strongly prefer to not block merging #18758 on such concerns. Even having a way to refer to inherent impl blocks is kinda a niche thing - what's the downstream usecase? I guess maybe as a place to hang docs.