Describe the bug
autocxx cannot handle C++ classes that contain std::unordered_map as a member, even if it's a private member and not directly referenced from Rust.
It appears that bindgen attempts to parse the internals of std::unordered_map, leading to unresolved template types like _Hashtable or _RehashPolicy.

To Reproduce

// code.h

#pragma once
#include <string>
#include <unordered_map>

class MyMapWrapper {
public:
    MyMapWrapper();
    void insert(const std::string& key, int value);

private:
    std::unordered_map<std::string, int> map_;
};

// code.cpp

#include "map_wrapper.hpp"

MyMapWrapper::MyMapWrapper() = default;
void MyMapWrapper::insert(const std::string& key, int value) {
    map_[key] = value;
}

// main.rs

use autocxx::prelude::*;
include_cpp! {
    #include "map_wrapper.hpp"
    safety!(unsafe_ffi)
    generate!("MyMapWrapper")
}

fn main() {
    let mut wrapper = ffi::MyMapWrapper::new().within_box();
    wrapper.insert("hello".into(), 42);
}

// build.rs

fn main() {
    autocxx_build::Builder::new("src/main.rs", &["src"])
        .extra_clang_args(&["-std=c++17"])
        .build()
        .expect("autocxx build failed")
        .compile("autocxx-map-wrapper");
}

Error:

1 | ...; pub type __umap_hashtable = root :: std :: _Hashtable < RehashPolicy > ; # [repr (C)] pub struct unordered_map { M_h : root :: std :: unordered_map...
| ^^^^^^^^^^^^^ not found in this scope
|
help: you might be missing a type parameter
|

error[E0412]: type `_Hashtable` not found in this scope

About half of the time people report bugs, they're not readily reproducible. That wastes time for everyone. That's why it's incredibly useful to have a test case which definitely fails. Thanks!

Expected behavior
If a type like unordered_map is used privately and not directly referenced in Rust, I’d expect it to be ignored or treated as opaque, or at least not cause bindgen to fail by inspecting internal STL templates.

Additional context
I understand this may be due to how bindgen interacts with STL internals. A workaround using the PIMPL idiom resolves the issue, but it's a workaround that requires altering otherwise valid C++ interfaces. It would be helpful if autocxx could either automatically treat STL-heavy members as opaque or provide a way to ignore private template members in generation.