Drop truncated package name prefix from package keys

Early on when we moved to package keys, we decided it would be useful for documentation purposes to have a package key be something like ghcpr_8TmvWUcS1U1IKHT0levwg3 rather than just 8TmvWUcS1U1IKHT0levwg3, which would leave a user with no idea what the key is.

I now think that this is more trouble than its worth:

1. We have fixed library *paths* so that the full package name, version, key is in the path, e.g. libraries are installed to /home/ezyang/Dev/ghc-7.10.2/usr/lib/ghc-7.10.2/ghc-prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3 instead of /home/ezyang/Dev/ghc-7.10.1/usr/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3. This means that the biggest case where users might care about package keys is no longer relevant; a user will always be able to get the real package key.
2. The other case where package keys show up is in symbol names. However, symbol names already contain *modules names*, so today we have procezu0hwN3CTKynhHQqQkChnSdH_SystemziProcess_rawSystem1_info but 0hwN3CTKynhHQqQkChnSdH_SystemziProcess_rawSystem1_info seems just about as clear (in particular, five letters just doesn't seem like enough to adequately describe long package names.)
3. Now, the reason why we don't want to truncate the prefix name is because it makes it more difficult to reliably, deterministically generate a package key based on a few parameters about a package: namely, any algorithm needs to know that take 5 (filter (/= '-') packageName) and prefix that onto the key. Really, we only care about the hash, but for most equality tests the prefix matters too! So it would be much nicer if we didn't have to care about the hash as well.

Trac metadata

Trac field	Value
Version	7.11
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Package system
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture