Fix logic to find real module path

[boschmitt]

Description

With python device kernel interoperability, users can write quantum kernels in C++ and bind them to python. In such cases, the common pattern is to have a C++ module that gets imported into a python module.

For example, if we have a python package named foo to which we add C++ extensions using pybind11. The common pattern is to end up with a with a module named _cppfoo (or whaterver). Then, we import all of its symbols to foo:

foo/__init__.py:
  from ._cppfoo import *

Now, if _cppfoo contains a binded device kernel named bar, then users are able to access it using foo.bar(...). This, however, is not the real path of bar, the real path is foo._cppfoo.bar(..).

Curently, binded device kernels get registered with their real path name, and thus when the python AST bridge parse another kernel that uses foo.bar(...), it needs to figure it out if that is its real path or not.

This commit attemps to improve the robustness of discovering this real path because as-is it fails on some simple cases.

This is how it works: In Python, many objects have a module attribute, which indicates the module in which the object was defined. This should be the case for functions. Thus the idea here is to walk the provide path until we reach the function object and ask it for its __module__.

[khalatepradnya]

Changes look good to me. Thanks, Bruno!
(Open Q on where / how to test)

[boschmitt]

Changes look good to me. Thanks, Bruno! (Open Q on where / how to test)

Thanks @khalatepradnya. I open an issue, #2348, on this. There I created a patch that breaks the current implementation. Unfortunately, my current fix is not working, it breaks other corner cases. I will keep looking more into to it.