Constant folding may turn the address of a stub into the address of its imported function

For the following C code:

```c
#include
__declspec(dllimport) void abort(void);
typedef void (*P)(void);
P p1 = abort;
const P p2 = abort;
int main() {
printf("p1\t%p\n", (void *)p1);
printf("p2\t%p\n", (void *)p2);
P p3 = *(const volatile P *)&p2;
printf("p3\t%p\n", (void *)p3);
printf("abort\t%p\n", (void *)abort);
}
```

A possible output is ([CE](https://godbolt.org/z/TcdxbP6bK)):

```
p1 00007FF7D81E3208
p2 00007FFCEE93CAA0
p3 00007FF7D81E3208
abort 00007FFCEE93CAA0
```

The object `p2` holds the same value as `p1` - that is, the address of the stub. However, when the value of the expression `p2` is printed, it is folded into the expression `abort`, which at block scope represents the address of the imported function. In other words, the expression `abort` evaluates to different values at file scope and block scope, but constant folding seemingly does not take that into account. In this case, it behaves like a macro substitution.

From the assembly, we can see that in the call to `printf`, the expression `p2` resolves to the entry `[__imp_abort]` (the imported function) instead of the symbol `abort` (the stub). This is an instance of miscompilation, although a minor one, since code does not usually depend on the address identity of a function.

Start by reproducing the C example from the issue and inspecting the generated assembly around the printf calls, especially the differing handling of p2, p3, and abort. Trace the constant-folding path for imported functions and file-scope versus block-scope expressions. Done means p2 retains the address stored in the object rather than folding to the imported function address, with a regression test for the example.

Written by the indexing model from the issue text.