Consider disallowing std hashmap/hashset via clippy

[Jefffrey]

We have a clippy config for disallowing types:

datafusion/clippy.toml

Lines 6 to 8 in 3ea21aa

	disallowed-types = [
	{ path = "std::time::Instant", reason = "Use `datafusion_common::instant::Instant` instead for WASM compatibility" },
	]

In datafusion-common we re-export hashbrown hashmaps/hashsets to encourage usage of them over std versions:

datafusion/datafusion/common/src/lib.rs

Lines 113 to 121 in 3ea21aa

	// The HashMap and HashSet implementations that should be used as the uniform defaults
	pub type HashMap<K, V, S = DefaultHashBuilder> = hashbrown::HashMap<K, V, S>;
	pub type HashSet<T, S = DefaultHashBuilder> = hashbrown::HashSet<T, S>;
	pub mod hash_map {
	pub use hashbrown::hash_map::Entry;
	}
	pub mod hash_set {
	pub use hashbrown::hash_set::Entry;
	}

• Introduce HashMap and HashSet type aliases #13236
• Use a single HashMap implementation consistently across the code base #677

Consider using clippy to enforce this?

[Phaneendra293]

This seems straightforward to enforce via Clippy.
If the maintainers agree with the approach, I’d be happy to work on adding the disallowed-types entries. Please let me know if I can take this, and feel free to assign it to me.

[Jefffrey]

Assigned @Phaneendra293

[Phaneendra293]

https://github.com/apache/datafusion/actions/runs/21111419936/job/60710657264?pr=19872.
Here is the attached PR(Pull request). In the above URL, clippy test case is failing because there is already usage of types that are now disallowed, like HashMap and HashSet from the std lib. Should I raise a new issue for changing disallowed to allowed alternatives?