Loosen shadowing check inside macro contexts.

[davidv1992]

This allows macro code to use identifiers for local variables which
are also defined as statics/consts/ctors outside of the macro. This
improves robustness of macro hygiene, as identifiers used inside a
macro can no longer produce unexpected restrictions on names for
statics and consts defined outside of it. Concretely, constructions
such as

thread_local!(static FOO: usize = 0);
static init: usize = 0;

no longer unexpectedly fail to compile because thread_local! happens
to define a function with init as a parameter name.

This fixes #99018

[rust-highfive]

r? @jackh726

(rust-highfive has picked a reviewer for you, use r? to override)

[jackh726]

Probably needs lang FCP, but this isn't my area of expertise

r? @petrochenkov

[davidv1992]

Hmm, did a further check today that I forgot yesterday, turns out there is also still a bug in my fix, in that it now doesn't complain about shadowing in the following code:

macro_rules! h {
    () => {
        static x: usize = 2;
        fn a(x: usize) -> usize {
            x + 2
        }
    }
}

h!();

fn main() {}

I will dive deeper into this next weekend when I have some time.

[petrochenkov]

thread_local is a macro_rules, and macro_rules do not provide hygiene for items.
Adjusting macro_rules hygiene to work for items in one specific case is certainly not a good idea.

[petrochenkov]

Closing as motivated by #99191 (comment), macro_rules are supposed to be transparent for item names.