Is there a specific philosophy that this repo has about using `pybind11_stubgen`-defined classes in the generated stubs? At the moment, I see that this is done mainly for `--numpy-array-wrap-with-annotated` with `pybind11_stubgen.typing_ext.FixedSize` and `pybind11_stubgen.typing_ext.DynamicSize("m", "n")`, although I am also seeing it in #199. My main concern with not making this choice explicit is that a lot of projects incorporating `pybind11_stubgen` into their builds might **only** include `pybind11_stubgen` as a build dependency and not as a required dependency of the whole project. This would mean users installing these projects would not have `pybind11_stubgen` installed, and type checkers would fail to resolve these expressions, in part or in full. There are a few non-mutually exclusive options that I can think of: 1. Do not use `pybind11_stubgen`-defined classes at all in generated stubs. I think this is the safest default approach. 2. Inject definitions for these `pybind11_stubgen`-defined classes into the generated stubs. Maybe as `Protocol`s? Would this mean re-defining a `FixedSize` protocol in every file it is used in? 3. Allow importing from `pybind11_stubgen`, with the user explicitly acknowledging that they must mark `pybind11_stubgen` as a required dependency of their project in order to fully utilize the generated stubs.