Record expansion_that_defined into crate metadata

[Aaron1011]

Fixes#77523

Now that hygiene serialization is implemented, we also need to record
expansion_that_defined so that we properly handle a foreign
SyntaxContext.

[rust-highfive]

r? @davidtwco

(rust_highfive has picked a reviewer for you, use r? to override)

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 8d11f90 with merge 9719ee19ad8fd331906c6ab78cf9fae776a46228...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 9719ee19ad8fd331906c6ab78cf9fae776a46228 (9719ee19ad8fd331906c6ab78cf9fae776a46228)

[rust-timer]

Queued 9719ee19ad8fd331906c6ab78cf9fae776a46228 with parent ea7e131, future comparison URL.

[rust-timer]

Finished benchmarking try commit (9719ee19ad8fd331906c6ab78cf9fae776a46228): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[estebank]

r? @estebank
@bors r+ rollup

[bors]

📌 Commit 8d11f90 has been approved by estebank

[Aaron1011]

Note that this might cause some breakage - if I understand this code correctly, we might now match a different identifier if we had both a def-site-identifier and non-def-site-identifier in scope. However, def-site hygiene is nightly only, so this should only be able to affect code using nightly features.

[estebank]

As you point out, the potential breakage would be only for nightly users and this new behavior clearly more correct than what we had. We can run crater if you think it is needed.

[Aaron1011]

I think we should be fine without a crater run - I don't know if @petrochenkov feels differently.