[BUG] Should steer pybind11's internal ABI away from STL types to make them work cross-compiler

Shifting discussion from here:
https://github.com/pybind/pybind11/pull/2772#discussion_r553654510

From @henryiii:

Also, I thought standard library templated classes were not valid in an ABI (@jpivarski)? I take it this is why we have so many issues with the ABI? Could we redesign this to just be simple classes and do our own memory management here?

His expansion on this:

These macros are evil; they force us to match extensions with exact compilers; while it would be much nicer to be able to interact with any extension that has a matching ABI flag. I think it's because we have lots of STL in our ABI, which causes it to be very picky; if we only interacted through standard types, and internally/externally handled the memory and such, then we could get rid of these macros entirely. That would be the direction to move, rather than adding more (like a string). But it's not "new" to a string.

PyTorch ignores these macros, because the internal JIT compiler may not match the host compiler (the JIT compiler just stores the host's definition of these macros and uses them, IIRC). At least one other user needed this to talk between different compilers, as well, for CUDA I think.

If we bump the ABI version, we'll need to coordinate with conda-forge, they pin on ABI versions and have to trigger a migration (I think) if it gets bumped.

TLDR: for now, if we can keep the ABI the same, that's best. Eventually we will need a bump. In the future, maybe we can design internals that work cross-compiler?

\cc @YannickJadoul @wjakob @rwgk

Start with the discussion on pull request #2772, then inspect pybind11's ABI macros and internal STL types referenced by that discussion. The issue does not name files, tests, or a concrete acceptance criterion; completion would require an agreed cross-compiler ABI design and validation plan.