🧑‍💻 Base Example Device on Template

[ystade]

Description

This PR refactors the example device implementation by instantiating the device template for the example device. This adds a couple of convieniet features to the example device like install instructin and the packaging as a python package.

Checklist:

• The pull request only contains commits that are focused and relevant to this change.
• I have added appropriate tests that cover the new/changed functionality.
• I have updated the documentation to reflect these changes.
• I have added entries to the changelog for any noteworthy additions, changes, fixes, or
  removals.
• I have added migration instructions to the upgrade guide (if needed).
• The changes follow the project's style guidelines and introduce no new warnings.
• The changes are fully tested and pass the CI checks.
• I have reviewed my own code changes.

[burgholzer]

@ystade This can be rebased now that #325 is merged.

[ystade]

@burgholzer I just realized that including also the constants.h in the dynamic library may lead to conflicts when linking devices statically together. In that scenario, the contained types will be defined twice (because they are contained in header files with different names even). I put that here even though this was done in #325 because it also influences this PR and this one is still open.

[burgholzer]

@burgholzer I just realized that including also the constants.h in the dynamic library may lead to conflicts when linking devices statically together. In that scenario, the contained types will be defined twice (because they are contained in header files with different names even). I put that here even though this was done in #325 because it also influences this PR and this one is still open.

Yeah, I had some intuition that something like this might come up.
I was hoping that it's fine as long as those are defined in separate translation units. But that is probably not the case when thinking about a driver that connects to multiple devices, like in MQT Core.
This should be moderately easy to find out though, right? We simply update the QDMI version in MQT Core to the latest v1.2.x commit and adjust the code to rely on the respective device headers... and see whether it crashes.
Or am I overlooking things?

[ystade]

@burgholzer THis should actually be enough, yes.

[burgholzer]

Alright, I actually tried this out real quick (updated the QDMI ref, removed the qdmi::qdmi link target from the devices, compiled), and it does lead to problems at least in MQT Core; particularly because of https://github.com/munich-quantum-toolkit/core/blob/main/include/mqt-core/qdmi/common/Common.hpp where we define common, device independent helpers.

So something definitely needs to change.
An option here would be to also prefix the enum definitions. Then there would have to be some casting down the line somewhere between the generic enum and the prefixed one.

We could also try to work it out in MQT Core by restructuring the common helper (which eventually should be moved here) and compiling the devices we have over there as shared libraries.
Feels like this could work, but we would lose the ability to link devices statically.

[burgholzer]

@ystade Based on the latest changes from the docs update, this now needs to be updated to resolve the conflicts.

Edit: I also think that once we get this PR in, and we figured out how to proceed with the constants.h header, it is time for the v1.2.2 release.