Update the unification work required for the external package development

[maliasadi]

This PR fixes the following issues.

1. The Lightning Monorepo doesn’t consider dependent external package development:
   • The core libraries are not interfaced and cannot be accessed
   • The simulator libraries are not interfaced and cannot be accessed.
2. Catalyst extends StateVectorLQubit by implementing a managed-like state-vector class with dynamic qubit management. To add this support,
   • The num_qubits_ needs to be a "protected" class variable so that it can be updated dynamically in StateVectorLQubitDynamic.
   • The implementation of simulators’ algorithms, observables, measurements should be updated to support any concrete implementation of StateVectorLQubit.

[sc-43458]

[github-actions]

Hello. You may have forgotten to update the changelog!
Please edit .github/CHANGELOG.md with:

• A one-to-two sentence description of the change. You may include a small working example for new features.
• A link back to this PR.
• Your name (or GitHub username) in the contributors section.

[codecov]

Codecov Report

Patch coverage: 100.00% and project coverage change: +6.04% 🎉

Comparison is base (869bbb8) 93.04% compared to head (60aad8b) 99.09%.
Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #482      +/-   ##
==========================================
+ Coverage   93.04%   99.09%   +6.04%     
==========================================
  Files         142      142              
  Lines       16278    16693     +415     
==========================================
+ Hits        15146    16542    +1396     
+ Misses       1132      151     -981     

Files Changed	Coverage Δ
...tning/core/src/simulators/base/StateVectorBase.hpp	100.00% <ø> (ø)
...tning_qubit/gates/tests/Test_OpToMemberFuncPtr.cpp	18.46% <ø> (ø)
pennylane_lightning/core/_version.py	100.00% <100.00%> (ø)
.../simulators/lightning_kokkos/StateVectorKokkos.hpp	99.76% <100.00%> (+5.99%)	⬆️
...s/gates/tests/Test_StateVectorKokkos_Generator.cpp	100.00% <100.00%> (ø)
...os/gates/tests/Test_StateVectorKokkos_NonParam.cpp	100.00% <100.00%> (ø)
...okkos/gates/tests/Test_StateVectorKokkos_Param.cpp	100.00% <100.00%> (ø)
...s/lightning_kokkos/measurements/ExpValFunctors.hpp	100.00% <100.00%> (+43.06%)	⬆️
...ghtning_kokkos/measurements/MeasurementsKokkos.hpp	98.26% <100.00%> (+3.79%)	⬆️
...asurements/tests/Test_StateVectorKokkos_Expval.cpp	100.00% <100.00%> (ø)
... and 5 more

... and 9 files with indirect coverage changes

☔ View full report in Codecov by Sentry.

📢 Have feedback on the report? Share it here.

[mlxd]

Once the changes are added, I'll approve.

Also, the RTD builder is failing now. There is a PR needed to fix this open at #491 which will be necessary before merging.

[AmintorDusko]

Hi @maliasadi, I'm happy with having num_qubits changed to protected.
In terms of algorithms, measurements and observables, I would rather have an explicit reference/check with respect to the StateVectorLQubitCatalist than a catch-all that assumes that everything that is not StateVectorLQubitRaw will be StateVectorLQubitManaged-like.
This brings us to another topic. In terms of all we discussed, and continuous support for StateVectorLQubitCatalist, I think it would be a good call to have it added as a new StateVectorLQubit variant to Lightning. In this way, our CI/CD will make sure no change breaks it. For example, having num_qubits as private works very well for Lightning's needs so far, if we have a backend relying on it the team will always remember (or be remembered of) this constraint.

[mlxd]

Hey @maliasadi feel free to retag us for review once this is updated.

[mlxd]

Thanks @maliasadi
Fine with me to see this go through if it meets your needs

[AmintorDusko]

Happy to have this in, if this will help PennyLane catalyst!