🧱 Include MQT Core via FetchContent instead as submodule

[ystade]

Description

MQT Core was included as a submodule so far. This PR removes this submodule and uses the existing fetch content commands to include this dependency.

Furthermore, it adds a dependabot-like update workflow for the FetchContent-managed mqt-core dependency.

Checklist:

• The pull request only contains commits that are related to it.
• I have added appropriate tests and documentation.
• I have made sure that all CI jobs on GitHub pass.
• The pull request introduces no new warnings and follows the project's style guidelines.

[ystade]

This PR will only pass all test when a new release of MQT Core is build that contains the Neutral Atom Support. The version number is already incremented accordingly. If this is not desired, the last commit can also be reverted to reference the appropriate commit directly.

[ystade]

As far as I can see, this is also related to #418, and realises a part of it.

[burgholzer]

In principle, I am in favour of just merging this. There is one corner case, that gets worse with this change though: By not providing the submodule fallback, any initial build from a fresh clone will require internet access, i.e., it is no longer possible to build the project without network connection given a fresh clone.
In the long run, this shouldn't be an issue for the Python side of things once #418 is in since mqt-core will then be a build and runtime dependency and, as a result, always be available when installing the Python package.
For the C++-only side of the project, it might not be that clean. Sure, people could start installing mqt-core on their systems and then use the find_package part of FetchContent to get that version. This is probably what most packagers would do if they ever where to package our tools for things like FreeBSD, homebrew, conda-forge, etc.

None of the above is opposing this change. I just wanted to put this out there to spread awareness. I just triggered a new mqt-core release, which will be 2.5.0.

[burgholzer]

As far as I can see, this is also related to #418, and realises a part of it.

Yeah. There is some overlap here. And I think that is great. It further reduces the size of #418 and eliminates some of the changes there.

[burgholzer]

Another small drawback that I just noticed is that we kind of loose the automatic dependency updates (i.e., dependabot) for keeping the submodule up to date. But maybe this isn't too important as updates of mqt-core should be driven by demand anyways.

[burgholzer]

I just thought about this a little more. I think I would be fine with dropping the offline installation possibility given the fact that, this is hardly possible at the moment anyways since mqt-core also uses FetchContent without backing the dependencies up by git submodules.
As such, this was a rather weak argument.

I'd still like to keep the automatic updates though. However, it should be possible to write a rather simple GitHub workflow that periodically checks for new releases of mqt-core via the GitHub API and automatically opens a PR that updates the version correspondingly.
In the end, that's a simple regex parse of one particular file, a call to the GitHub API for checking if a new version is around, a regex replace with the new version number, and another GitHub API call for creating the update PR (there are actions for that).
I'll see whether I can make that work quickly and push a proposal to this branch.
If we find a solid enough solution for that here, then I would roll that solution out to all top-level repos that make use of mqt-core.

[burgholzer]

Alright. This is ready to go in ✅
Let's see how long it takes until the auto update workflow breaks 😅