Else, links to `char::foo` would point into `/path/to/src/libcore/std/primitive.char.html#method.foo`.

Split out from rust-lang#73804.

They both produce less-than-desirable output (links going to docs.rust-lang.org), but I haven't figured out yet how to assert about them properly.

For the two of these tests that have a local `char` to link to, this behavior isn't what's expected, but is what's happening presently.

This reverts commit ee3a0f8.

There don't seem to be any other compiletests that are 1) building a standalone "no_core" create and then 2) trying to link against it. There seems to be a platform-specific limitation in doing so:

```
2020-07-08T16:07:42.9419409Z   = note:    Creating library D:\a\rust\rust\build\i686-pc-windows-msvc\test\rustdoc\intra-link-prim-methods-external-core\auxiliary\my_core.dll.lib and object D:\a\rust\rust\build\i686-pc-windows-msvc\test\rustdoc\intra-link-prim-methods-external-core\auxiliary\my_core.dll.exp
2020-07-08T16:07:42.9419810Z           LINK : error LNK2001: unresolved external symbol __DllMainCRTStartup@12
2020-07-08T16:07:42.9420032Z           D:\a\rust\rust\build\i686-pc-windows-msvc\test\rustdoc\intra-link-prim-methods-external-core\auxiliary\my_core.dll : fatal error LNK1120: 1 unresolved externals
```

Possibly this could be resolved by adding a `__DllMainCRTStartup` or `__DllMainCRTStartup@12` symbol in an architecture- and platform-specific way.