Remove unused_extern_crates warning for crates used by nested code

[dtolnay]

In the following scenario, the user will have a better experience if we allow them to have an "unused" extern crate.

---

[playground]

//extern crate serde;

struct NotSerializable;

struct TryingToSerialize {
    bad: NotSerializable,
}

// Code generated by a macro like #[derive(Serialize)].
const IMPL_SERIALIZE_FOR_TryingToSerialize: () = {
    extern crate serde;

    impl serde::Serialize for TryingToSerialize {
        fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
            where S: serde::Serializer
        {
            serde::Serialize::serialize(&self.bad, serializer)
        }
    }
};

---

If we permit them to write extern crate, as recommended by Serde's docs for this reason, the error message is:

8 | #[derive(Serialize)]
  |          ^^^^^^^^^ the trait `serde::Serialize` is not implemented
                       for `NotSerializable`

If they remove the unused extern crate, they generally get nastier error messages.

8 | #[derive(Serialize)]
  |          ^^^^^^^^^ the trait `_IMPL_SERIALIZE_FOR_TryingToSerialize::_serde::Serialize`
                       is not implemented for `NotSerializable`

---

If we can't fix the error message to be as good as it was before the unused_extern_crates warning, let's disable unused_extern_crates in cases where the same crate is used later in some nested scope (submodule or code block).

---

cc @ishitatsuyuki who has been involved with this warning.

[ishitatsuyuki]

Arguable point. As the statement doesn't impact the binary (linkage), it doesn't harm if we disabled the lint. I'm not sure about the way to implement it though.

[Dylan-DPC-zz]

@dtolnay the above example works now without the requirement of extern crate. Is there anything else blocking this other than #46991?