Don't eagerly instantiate `CompletionItem`s

Currently when calculating completions we run our different functions to calculate the many different completions we want to offer, immediately turning all of them into the same CompletionItems. This has the downside that we lose a lot of valuable information, requiring us to do upfront decision on some things.

The main pain point here is the auto-insertion of borrows which is currently partially disabled, and for the small subset where it is enabled it is still bugged. What we can do instead is collect all calculated completions into some intermediate representation first which we can then render into the full items. This extra step would allow us to properly split items into multiple ones where desired, as is the case with auto-borrow completions. Similarly this would then also allow us to split completions into simple ones and ones with call argument/pattern destructuring snippets which appear and disappear every now and then due to some refactors.

This, after https://github.com/rust-lang/rust-analyzer/pull/12570 should be the last major refactoring required (in regards to what my view on the current completion infra is at least). Then we should be pretty damn close to being able to iron out all the small special cases for "perfect completions".

Start by reading the completion infrastructure and the changes in PR #12570 to understand how calculated completions become CompletionItems. Define an intermediate representation that preserves the information needed for auto-borrow and destructuring variants, then render the final items without eagerly discarding that information. Done means the refactor supports these completion variants without regressing existing completion behavior.