Warn about implicit hasher for HashMap

[clarfonthey]

A lot of libraries, particularly ones that interop with serde, should probably generalise impls over different BuildHashers for HashMap, but end up missing them and defaulting to the hasher. IMHO there should be a lint for blanket impls for HashMap which exclude the hasher, because in most cases you don't specifically depend on SipHasher.

Obviously, structs which simply include HashMap<K, V> inside of them can probably be left as-is.

For example, code like:

impl<K: Hash + Eq, V> Serialize for HashMap<K, V> { ... }

could be suggested to become

impl<K: Hash + Eq, V, S: BuildHasher> Serialize for HashMap<K, V, S> { ... }

We should probably check for specific uses of methods which require the default state, but otherwise lint on less-generic impls.

[sinkuu]

We should probably check for specific uses of methods which require the default state, but otherwise lint on less-generic impls.

I think we should be able to suggest generic version for these methods.

HashMap::new() => HashMap::default()
HashMap::with_capacity(cap) => HashMap::with_capacity_and_hasher(cap, Default::default())

[clarfonthey]

IMHO new and with_capacity should be modified to become the latter two, and clippy shouldn't just suggest to users to change their code.