[FEAT][RUST]Add tvm_ffi::Map in Rust

[Seven-Streams]

This PR adds tvm_ffi::Map in Rust.

tvm_ffi::MapObj`` in Rust and the ffi::MapObj in C++ share the same memory layer at run time(when TVM_FFI_DEBUG_WITH_ABI_CHANGE is False). and tvm_ffi::MapObj will call the corresponding method of ffi::Obj in C++ through global function call directly in most cases.

[gemini-code-assist]

Code Review

This pull request introduces an immutable Map container (Map<K, V>) backed by the C++ ffi.Map object, complete with iterators, type conversions, and comprehensive tests. It also adds a cached_global_func! macro to simplify global function caching. The feedback suggests implementing Send and Sync for Map<K, V> when K and V are Send and Sync, as the raw pointer in MapObj makes the type !Send and !Sync by default.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Since MapObj contains a raw pointer (*mut core::ffi::c_void), it is automatically !Send and !Sync by default. Consequently, Map<K, V> also becomes !Send and !Sync, which prevents it from being sent or shared across thread boundaries (e.g., when using std::thread::spawn or parallel iterators).

Since Map is an immutable, reference-counted container, it is safe to implement Send and Sync for it, provided that the key and value types also satisfy these bounds.

Consider adding explicit Send and Sync implementations for Map<K, V>.

Suggested change

	pub struct Map<K, V> {
	data: ObjectArc<MapObj>,
	_marker: PhantomData<(K, V)>,
	}
	pub struct Map<K, V> {
	data: ObjectArc<MapObj>,
	_marker: PhantomData<(K, V)>,
	}
	unsafe impl<K: Send + Sync, V: Send + Sync> Send for Map<K, V> {}
	unsafe impl<K: Send + Sync, V: Send + Sync> Sync for Map<K, V> {}