Replace EditionedFileId with a better abstraction

[Veykril]

The introduction of EditionedFileId was mainly meant to get edition-based parsing working fast with the 2024 edition coming up and some other things. It is kind of annoying to deal with though wrt to HirFileId as the IDE doesn't always have the edition at hand while already dealing with HirFileIds for the macro cases. That is, within the HIR layer, this abstraction works fairly well. But we need something else in the IDE layer I believe.

[ChayimFriedman2]

Maybe IDE doesn't always have the edition, but it is needed. How can we get rid of it?

If anything, I feel macro files are the awkward. The need to upmap them always lead to both bugs (where we forget to upmap), missing features (where we just give up and ignore macros) and just non-nice code. I'm not sure there's something we can do here though.

[Veykril]

Yes we do need the editions in IDE as well, but the current setup is tricky to get that right (the issue description is vague as it serves more of a note for myself to flesh out later).

If anything, I feel macro files are the awkward.

Yep our API is fairly prone to mishandling macros, that would in part be addressed by #17367 / carrying the file IDs with nodes and ranges instead of having semantics implicitly derive those from the node.

I am about to change where we upmap in a PR this week (maybe today even), pushing it out of the IDE layer (for reasons that will become clear then).