RFC to require `impl MyStruct` to be nearby the definition of `MyStruct`

This fixes #15060 and #3785.
I realized this has nothing to do with typeck, that's just where "module instead of type" is noticed. The reason that `Vec` in `impl<U: T> Vec<U>` resolves to a module here rather than a type is in `Resolver::def_for_namespace()`, which is eventually called from `Resolver::resolve_crate()`, the final function call of `Resolver::resolve()`. (The purpose of `resolve_crate()` is to go through once every `struct` and `impl` has been seen to resolve things completely.)

The way that `def_for_namespace()` works is to try and return a `DefType` first, which it will only find if the type `Vec` had been defined somewhere. Failing that, try and return a `DefMod`, which will be defined if an `impl Vec` or `struct Vec` had occured somewhere. Failing that, return None.

Notice that at no point are imports used when resolving `Vec`. This could happen when resolving `Vec::from_slice()` later on, in `Resolver::resolve_module_path()`, which first tries to find `Vec` in the current module, then failing that, resolves imports. (In fact this would not happen, since `Vec` would be found in the current module, as a module rather than type, thanks to the `impl Vec` and the anonymous trait module it creates.) But this doesn't even have a chance to happen, since, `resolve_module_path()` is never called when resolving `impl Vec`; `impl` blocks and functions become different beasts during the initial `build_reduced_graph()` run, so different code paths are taken in `resolve_crate()`. (And this makes sense, since when resolving `impl Vec` in `resolve_crate()`, we <i>know</i> that `Vec` will is in the module because we added it in `build_reduced_graph()` as an anonymous trait module. So there is no point in resolving imports.)