Fix #19071: ensure completion_item_hash serializes items uniquely

[cessen]

Previously it may have been possible for different completion items to produce colliding hashes, not because of the hash but because of how the items were serialized into byte streams for hashing. See #19071 for details.

The chances of that happening were low, if it was actually possible at all. Nevertheless, this commit ensures that it definitely can't happen.

This commit uses a handful of techniques used to fix this, but they all boil down to "ensure this could be re-parsed". If it's possible to parse to recreate the original item, then by construction there is no chance of two different items getting serialized to identical byte streams.

[lnicola]

r? @SomeoneToIgnore

[SomeoneToIgnore]

Looks nice to me, thank you for improving this.

The only question I have, after reading the issue: are 0u8, 1u8 and 2u8 really better than their string counterparts?
The issue mentions a + bc and ab + c uniqueness concern, but here I see that multiple different strings are mapped to the same digits (could_unify, non_exact and "&mut " were different but now are all 1u8) — is this really an improvement?
(should have read the comments too)

[lnicola]

I think it's an improvement in the sense we're hashing slightly less stuff. We're not going to get collisions for using the same discriminants (because we keep track of each field), but also I don't think it we could have gotten collisions before.