Simplify symbol version mangling

[brson]

In the spirit of stripping down and simplifying our broken versioning scheme (#10188, #10207), this is a suggestion to remove a bunch of complexity from our name mangling.

The description of how we mangle symbols is mostly correct. The most important thing this mangling gets us is that it allows multiple, different crates to define the functions by throwing in some hashes, and that's worth preserving. The other versioning benefits are theoretical and don't work.

Where the current mangling includes a hash of the crate metadata and the type signature and also a version tag, instead we can just add a unique hash that either represents the crate metadata as currently defined or the strict version hash as suggested in #10207.

cc #2166

[brson]

Nominating

[alexcrichton]

It's probably also worth mentioning that the other main reason for having this hash was to throw the type signature into the hash. Then in theory if you change the symbol's type you would prevent linking against the new crate with crates linked against the old version. That being said, our "in-place update" system is so broken as is (see #10207), that this is the least of our concerns.

I personally like the idea of this becoming the strict version hash instead of the crate metadata hash because if symbol names become truly not determined by node ids then we could very realistically run into this problem by accident. By using the SVH (which is extremely sensitive to crate changes), then we're still guaranteeing that you can't link against old versions of libraries.

[pnkfelix]

P-low, not necessary for 1.0. The theory is that we can probably fix this without anything breaking (apart from binary incompatibilities, but we're unlikely to guarantee that.)

[steveklabnik]

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#689