Codesplitting across reexports using symbol data

[mischnic]

Closes #7392

Symbol propagation already does the traversals anyway, so now it just always tracks for each symbol in a dependency, what that symbol should resolve to.

Then, once it encounters a non-reexport dependency, it checks if all symbols in that dependency resolve to the same asset, and rewrites the edge from the dependency to the asset to point to the original asset that has the symbol (or at least as far down as possible, in case some deopt or non-static situation was encountered).

Since it's possible to rename symbols via reexports, I've had to add an additional map to the dependency node, e.g. a dependency to a side-effect-free asset that does export {foo as bar} from "y"; would then be rewritten to point directly to y instead, and the symbolTarget map then has foo -> bar which is applied transparently in bundleGraph.getUsedSymbols and bundleGraph.getSymbols (which I think is a better solution compared to mutating the actual DependencyValue symbols entry).

• The major outstanding known issue: if we rewrite the dependency edge proper, we don't have the original edge anymore on the next build (if it's cached). So I think we have to have another edge type, which would be used instead of the untyped edge when converting the asset graph into the bundle graph.
• This currently only works if a dependency imports symbols that all eventually resolve to the same asset, otherwise it behaves just as before. So I think splitting up the imports to be per-symbol should happen in the JS transformer, otherwise we'd have a single dependency (id) that actually resolves to different assets. We might have to change how the dependency id is derived for that
• add tests for new behaviour
• real world testing

A pleasant surprise:
Doing import("lodash-es").then(({add}) => add(1,2)) will be redirected to behave like import("lodash-es/add").then(...)

[mischnic]

Superseded by #8432