Detect pybind11 version mismatches

[jnbrunet]

Thanks to @coolteemf who reported this issue.

When we are creating our own bindings inside an external plugin, class inheritance against a base class defined in SofaPython3 is possible if and only if the pybind11 version is the same for both projects.

From pybind11 documentation:

Note also that it is possible (although would rarely be required) to share arbitrary C++ objects between extension modules at runtime. Internal library data is shared between modules using capsule machinery 1 which can be also utilized for storing, modifying and accessing user-defined data. Note that an extension module will “see” other extensions’ data if and only if they were built with the same pybind11 version.

For example, the following:

┌─────────────────┐      ┌────────────────────────┐
│    MyPlugin     │      │       SofaPython3      │
│                 │      │                        │
│   Mycamera <-------------- BaseCamera           │
│                 │      │                        │
│                 │      └────────────────────────┘
└─────────────────┘

from Sofa.Core import Camera
from MyPlugin import MyCamera

is only possible if SofaPython3 and MyPlugin is compiled using exactly the same pybind11 version. Else, the following will happen:

>>> from Sofa.Core import Camera
>>> from MyPlugin  import MyCamera
[ERROR]   [SofaRuntime] ImportError: generic_type: type "MyCamera" referenced unknown base type "sofa::component::visualmodel::BaseCamera"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>

This error is not so trivial to debug, and we could easily detect it at the CMake stage by verifying pybind11 version match. We could, for example, insert the current pybind11 version inside an exported CMake's target property. @guparan, do you think this could be feasible?