♻️ Refactor EquivalenceCheckingManager and 📝✨ Revamp Documentation (#566)

## Description

This pull request includes several enhancements and updates across the
project and associated documentation:

1. Updated dependencies such as `mqt-core` and pre-commit hooks to their
latest versions.
2. Refactored `EquivalenceCheckingManager` to streamline its public
interface by removing redundant methods.
2. Modernized project documentation and added a citation file for
referencing.
3. Improved the structure of Python tests and slightly revamped the
Python package with better documentation.
4. Adjusted Python bindings by moving documentation to stubs and refined
counterexample handling for better flexibility.
5. Incorporated smaller code quality improvements.
6. Updated the Read the Docs (RtD) build configuration.

This contains some breaking changes on the C++ as well as the Python
side. However, these should simplify the usage of the library and
generally reduce the size of the code base. With the 3.0 release coming
up, this is the time for making such changes.

At least locally, it also looks like this will fix #546. That still
needs to be verified though.

## Checklist:

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

Author: burgholzer

.clang-tidy

@@ -1,7 +1,6 @@
 FormatStyle: file
 
 Checks: |
-  boost-*,
   bugprone-*,
   -bugprone-easily-swappable-parameters,
   -bugprone-unchecked-optional-access,

.github/contributing.md

@@ -0,0 +1,78 @@
+# Contributing
+
+Thank you for your interest in contributing to this project.
+We value contributions from people with all levels of experience.
+In particular if this is your first pull request not everything has to be perfect.
+We will guide you through the process.
+
+We use GitHub to [host code](https://github.com/cda-tum/mqt-core), to [track issues and feature requests](https://github.com/cda-tum/mqt-core/issues), as well as accept [pull requests](https://github.com/cda-tum/mqt-core/pulls).
+See <https://docs.github.com/en/get-started/quickstart> for a general introduction to working with GitHub and contributing to projects.
+
+## Types of Contributions
+
+You can contribute in several ways:
+
+- 🐛 Report Bugs
+  : Report bugs at <https://github.com/cda-tum/mqt-qcec/issues> using the _🐛 Bug report_ issue template. Please make sure to fill out all relevant information in the respective issue form.
+
+- 🐛 Fix Bugs
+  : Look through the [GitHub Issues](https://github.com/cda-tum/mqt-qcec/issues) for bugs. Anything tagged with "bug" is open to whoever wants to try and fix it.
+
+- ✨ Propose New Features
+  : Propose new features at <https://github.com/cda-tum/mqt-qcec/issues> using the _✨ Feature request_ issue template. Please make sure to fill out all relevant information in the respective issue form.
+
+- ✨ Implement New Features
+  : Look through the [GitHub Issues](https://github.com/cda-tum/mqt-qcec/issues) for features. Anything tagged with "feature" or "enhancement" is open to whoever wants to implement it. We highly appreciate external contributions to the project.
+
+- 📝 Write Documentation
+  : MQT QCEC could always use some more documentation, and we appreciate any help with that.
+
+## Get Started 🎉
+
+Ready to contribute? Check out the {doc}`Development Guide <development_guide>` to set up MQT QCEC for local development and learn about the style guidelines and conventions used throughout the project.
+
+We value contributions from people with all levels of experience.
+In particular, if this is your first PR, not everything has to be perfect.
+We will guide you through the PR process.
+Nevertheless, please try to follow the guidelines below as well as you can to help make the PR process quick and smooth.
+
+## Core Guidelines
+
+- ["Commit early and push often"](https://www.worklytics.co/blog/commit-early-push-often).
+- Write meaningful commit messages, preferably using [gitmoji](https://gitmoji.dev) for additional context.
+- Focus on a single feature or bug at a time and only touch relevant files. Split multiple features into separate contributions.
+- Add tests for new features to ensure they work as intended. Document new features appropriately.
+- Add tests for bug fixes to demonstrate that the bug has been resolved.
+- Document your code thoroughly and ensure it is readable.
+- Keep your code clean by removing debug statements, leftover comments, and unrelated code.
+- Check your code for style and linting errors before committing.
+- Follow the project's coding standards and conventions.
+- Be open to feedback and willing to make necessary changes based on code reviews.
+
+## Pull Request Workflow
+
+- Create PRs early. It is ok to create work-in-progress PRs. You may mark these as draft PRs on GitHub.
+- Describe your PR with a descriptive title, reference any related issues by including the issue number in the PR description, and add a comprehensive description of the changes. Follow the provided PR template and do not delete any sections, except for the issue reference if your PR is not related to an issue.
+- Whenever a PR is created or updated, several workflows on all supported platforms and versions of Python are executed. These workflows ensure that the project still builds, all tests pass, the code is properly formatted, and no new linting errors are introduced. Your PR must pass all these continuous integration (CI) checks before it can be merged.
+- Once your PR is ready, change it from a draft PR to a regular PR and request a review from one of the project maintainers. Only request a review once you are done with your changes and the PR is ready to be reviewed. If you are unsure whether your PR is ready, ask in the PR comments. If you are a first-time contributor, request a review from one of the maintainers by mentioning them in a comment on the PR.
+- If your PR gets a "Changes requested" review, address the feedback and update your PR by pushing to the same branch. Do not close the PR and open a new one. Respond to review comments on the PR (e.g., with "done 👍" or "done in @<commit>") to let the reviewer know that you have addressed the feedback. Note that reviewers do not get a notification if you just react to the review comment with an emoji. Write a comment to notify the reviewer. Do not resolve the review comments yourself. The reviewer will mark the comments as resolved once they are satisfied with the changes.
+- Be sure to re-request a review once you have made changes after a code review so that maintainers know that the requests have been addressed.
+- No need to squash commits before merging; we usually squash them to keep the history clean. We only merge without squashing if the commit history is clean and meaningful. Avoid rebasing or force-pushing your PR branch before merging, as it complicates reviews. You can rebase or clean up commits after addressing all review comments if desired.
+
+Here are some tips for finding the cause of certain failures:
+
+- If any of the `CI / 🇨‌ Test` checks fail, this indicates build errors or test failures in the C++ part of the code base. Look through the respective logs on GitHub for any error or failure messages.
+- If any of the `CI / 🐍 Test` checks fail, this indicates build errors or test failures in the Python part of the code base. Look through the respective logs on GitHub for any error or failure messages.
+- If any of the `codecov/\*` checks fail, this means that your changes are not appropriately covered by tests or that the overall project coverage decreased too much. Ensure that you include tests for all your changes in the PR.
+- If `cpp-linter` comments on your PR with a list of warnings, these have been raised by `clang-tidy` when checking the C++ part of your changes for warnings or style guideline violations. The individual messages frequently provide helpful suggestions on how to fix the warnings. If you don't see any messages, but the `🇨‌ Lint / 🚨 Lint` check is red, click on the `Details` link to see the full log of the check and a step summary.
+- If the `pre-commit.ci` check fails, some of the `pre-commit` checks failed and could not be fixed automatically by the _pre-commit.ci_ bot. Such failures are most likely related to the Python part of the code base. The individual log messages frequently provide helpful suggestions on how to fix the warnings.
+- If the `docs/readthedocs.org:\*` check fails, the documentation could not be built properly. Inspect the corresponding log file for any errors.
+
+---
+
+This document was inspired by and partially adapted from
+
+- <https://matplotlib.org/stable/devel/coding_guide.html>
+- <https://opensource.creativecommons.org/contributing-code/pr-guidelines/>
+- <https://yeoman.io/contributing/pull-request.html>
+- <https://github.com/scikit-build/scikit-build>

.github/contributing.rst

@@ -0,0 +1,11 @@
+# Support
+
+If you are stuck with a problem using MQT QCEC or have questions, please get in touch at our [Issues](https://github.com/cda-tum/mqt-qcec/issues) or [Discussions](https://github.com/cda-tum/mqt-qcec/discussions). We'd love to help.
+
+You can save time by following this procedure when reporting a problem:
+
+- Do try to solve the problem on your own first.
+- Search through past [Issues](https://github.com/cda-tum/mqt-qcec/issues) and [Discussions](https://github.com/cda-tum/mqt-qcec/discussions) to see if someone else already had the same problem.
+- Before filing a bug report, try to create a minimal working example (MWE) that reproduces the problem. It is much easier to identify the cause for the problem if a handful of lines suffice to show that something is not working.
+
+You can also always reach us at [quantum.cda@xcit.tum.de](mailto:quantum.cda@xcit.tum.de).

.github/support.md

@@ -107,7 +107,7 @@ repos:
           - nox
           - numpy
           - pytest
-          - mqt.core>=3.0.0b4
+          - mqt.core>=3.0.0b6
 
   # Check for spelling
   - repo: https://github.com/crate-ci/typos
@@ -144,3 +144,21 @@ repos:
     rev: 2025.02.24
     hooks:
       - id: validate-pyproject
+
+  # Tidy up BibTeX files
+  - repo: https://github.com/FlamingTempura/bibtex-tidy
+    rev: v1.14.0
+    hooks:
+      - id: bibtex-tidy
+        args:
+          [
+            "--align=20",
+            "--curly",
+            "--months",
+            "--blank-lines",
+            "--sort",
+            "--strip-enclosing-braces",
+            "--sort-fields",
+            "--trailing-commas",
+            "--remove-empty-fields",
+          ]

.github/support.rst

@@ -1,39 +1,42 @@
 version: 2
 
 formats:
-  #  - pdf
+  - pdf
   - htmlzip
 
 build:
   os: ubuntu-24.04
   tools:
     python: "3.12"
-  commands:
-    # Skip docs build if the commit message contains "skip ci"
-    - (git --no-pager log --pretty="tformat:%s -- %b" -1 | grep -viq "skip ci") || exit 183
-    # Skip docs build if there are no changes related to docs
-    - |
-      if [ "$READTHEDOCS_VERSION_TYPE" = "external" ] && git diff --quiet origin/main -- docs/ .readthedocs.yaml src/mqt/ src/python include/*/python .github/contributing* .github/support*;
-      then
-        exit 183;
-      fi
-    # Set up uv and a virtual environment
-    - asdf plugin add uv
-    - asdf install uv latest
-    - asdf global uv latest
-    # Unshallow the git clone and fetch tags to get proper version information
-    - git fetch --unshallow --tags
-    # Run the html builder
-    - uv run --frozen --no-dev --group docs -m sphinx -T -b html -d docs/_build/doctrees -D language=en docs/source $READTHEDOCS_OUTPUT/html
-    # Run the htmlzip builder and create a zip file
-    - uv run --frozen --no-dev --group docs -m sphinx -T -b dirhtml -d docs/_build/doctrees -D language=en docs/source docs/_build/dirhtml
-    - mkdir -p $READTHEDOCS_OUTPUT/htmlzip
-    - zip -r $READTHEDOCS_OUTPUT/htmlzip/html.zip docs/_build/dirhtml/*
-    # Run the latex builder and create a pdf file
-#    - uv run --frozen --no-dev --group docs -m sphinx -T -b latex -d docs/_build/doctrees -D language=en docs/source docs/_build/latex
-#    - cd docs/_build/latex && latexmk -pdf -f -dvi- -ps- -interaction=nonstopmode -jobname=$READTHEDOCS_PROJECT
-#    - mkdir -p $READTHEDOCS_OUTPUT/pdf
-#    - cp docs/_build/latex/$READTHEDOCS_PROJECT.pdf $READTHEDOCS_OUTPUT/pdf/$READTHEDOCS_PROJECT.pdf
-
-sphinx:
-  configuration: docs/conf.py
+  apt_packages:
+    - graphviz
+    - inkscape
+  jobs:
+    post_checkout:
+      # Skip docs build if the commit message contains "skip ci"
+      - (git --no-pager log --pretty="tformat:%s -- %b" -1 | grep -viq "skip ci") || exit 183
+      # Skip docs build if there are no changes related to docs
+      - |
+        if [ "$READTHEDOCS_VERSION_TYPE" = "external" ] && git diff --quiet origin/main -- docs/ .readthedocs.yaml src/mqt/ src/python include/*/python .github/contributing* .github/support*;
+        then
+          exit 183;
+        fi
+      # Unshallow the git clone and fetch tags to get proper version information
+      - git fetch --unshallow --tags
+    pre_build:
+      # Set up uv
+      - asdf plugin add uv
+      - asdf install uv latest
+      - asdf global uv latest
+    build:
+      html:
+        - uv run --frozen --no-dev --group docs -m sphinx -T -b html -d docs/_build/doctrees -D language=en docs $READTHEDOCS_OUTPUT/html
+      htmlzip:
+        - uv run --frozen --no-dev --group docs -m sphinx -T -b dirhtml -d docs/_build/doctrees -D language=en docs docs/_build/dirhtml
+        - mkdir -p $READTHEDOCS_OUTPUT/htmlzip
+        - zip -r $READTHEDOCS_OUTPUT/htmlzip/html.zip docs/_build/dirhtml/*
+      pdf:
+        - uv run --frozen --no-dev --group docs -m sphinx -T -b latex -d docs/_build/doctrees -D language=en docs docs/_build/latex
+        - cd docs/_build/latex && latexmk -pdf -f -dvi- -ps- -interaction=nonstopmode -jobname=$READTHEDOCS_PROJECT
+        - mkdir -p $READTHEDOCS_OUTPUT/pdf
+        - cp docs/_build/latex/$READTHEDOCS_PROJECT.pdf $READTHEDOCS_OUTPUT/pdf/$READTHEDOCS_PROJECT.pdf