Splitting matrix operations, refactor dispatcher, add a benchmark suite for all gates/generators/matrices

[chaeyeunpark]

Before submitting

Please complete the following checklist when submitting a PR:

• All new features must include a unit test.
  If you've fixed a bug or added code that should be tested, add a test to the
  tests directory!

• All new functions and code must be clearly commented and documented.
  If you do make documentation changes, make sure that the docs build and
  render correctly by running make docs.

• Ensure that the test suite passes, by running make test.

• Add a new entry to the .github/CHANGELOG.md file, summarizing the
  change, and including a link back to the PR.

• Ensure that code is properly formatted by running make format.

When all the above are checked, delete everything above the dashed
line and fill in the pull request template.

---

Context: While working with kernels (two existing and AVX kernels to be added), it is found that implementing the general applyMatrix method that works for all different numbers of wires is rather difficult/impractical. Thus this PR splits this method into three (applySingleQubitOp/applyTwoQubitOp/applyMultiQubitOp). In addition, a dispatching procedure is refactored to separate a module for selecting the best kernel (which is now only done in StateVector) and calling a kernel function (completely done in the DynamicDispatcher class). Benchmark suites are updated accordingly.

Description of the Change:

Benefits: Faster applyMatrix for general single-qubit and two-qubit gates. Easy to add a mechanism to choose the best-performing kernel for the given number of qubits (one of the following PRs). Easy to benchmark all gate/generator/matrix operations.

Possible Drawbacks:

Related GitHub Issues:

[maliasadi]

Great work @chaeyeunpark! I have a few questions, but no blocking concerns and happy to approve afterwards.

[mlxd]

Hey @chaeyeunpark as mentioned, amazing work putting this together.

Though, I do think due to the complexity here and change in architecture that we need to add supporting documentation and guides for this. I think many of us may need to relearn how everything works here to be able to contribute further to Lightning. What are your thoughts?

[maliasadi]

Great work @chaeyeunpark! I don't have anything else to add. Happy to approve 🎉

[chaeyeunpark]

Hi @mlxd, I updated some documents (https://pennylane-lightning--274.org.readthedocs.build/en/274/benchmark.html and https://pennylane-lightning--274.org.readthedocs.build/en/274/add_kernel.html). As subsequent PRs will add more changes in dispatch mechanisms, I think it is better to add more details to the documents in those PRs.

[mlxd]

💯