Clarify some interning details

`Interned` does pointer equality/hashing, which is valid in two cases.
- The values are guaranteed to be unique (e.g. via interning, or
  construction). This is how `rustc_middle` uses `Interned`.
- The type has "identity" and different values should be considered
  distinct even if they are identical. This is how `rustc_resolve` uses
  `Interned`.

PR 137202 tried to clarify things by adding a `T: Hash` constraint to
`Interned<'a, T>`. This constraint isn't actually used, because
`Interned` is hashed based on pointer value, not contents. But it was
intended to communicate the idea that a type stored in `Interned` is
actually interned, which is likely to be done with hashing. Panicking
impls of `Hash` were added for the relevant `rustc_resolve` types to
work around the fact that it doesn't use hashing-based interning.

In my opinion PR 137202 didn't improve things. The `T: Hash` constraint
is only aimed at the interning case, and even for that case it's not
quite right because you could use a `BTreeMap` to intern instead of a
`HashMap`.

This commit does several things.
- Removes the `T: Hash` constraint and the `Hash` impls for
  `rustc_resolve` types added in PR 137202.
- Improves the comments on `Interned` to cover the non-interning cases.
- Removes the `PartialOrd`/`Ord` impls on `Interned` because (a) they're
  not used, and (b) their meaning is unclear for the "identity" case.
- Improves the documentation in `rustc_resolve` to explain how
  `Interned` usage is valid there.