Importing the default.tensor in PL from the lightning.tensor device in PL lightning

[PietropaoloFrisoni]

Context: This PR moves part of the lightning.tensor device from PennyLane lightning to PennyLane. Such a device was introduced originally in the following pull requests: 1 and 2. Due to requirements change, it has been decided to create an additional default.tensor device and move it to the PennyLane repository. Specifically, we move the quimb interface and the corresponding Python implementation of lightning.tensor into default.tensor. For reference, the PR removing such a component from lightning.tensor is here.

Please note that the full documentation for such a device will be added in a following PR (#5719)

Description of the Change: As above.

Benefits: Having two separate devices simplifies the distinction between the C++ and the Python components. The relationship between lightning.tensor and default.tensor will be similar to that between lightning.qubit and default.qubit.

Possible Drawbacks: None with the existing code, since this is a new quantum device.

Related GitHub Issues: None.

Related Shortcut Stories:
[sc-63256]
[sc-62979]

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.67%. Comparing base (b7b4b75) to head (a747fd7).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #5699      +/-   ##
==========================================
- Coverage   99.68%   99.67%   -0.01%     
==========================================
  Files         415      416       +1     
  Lines       38898    38745     -153     
==========================================
- Hits        38774    38620     -154     
- Misses        124      125       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mudit2812]

Looks good. I don't think it makes sense to have simulate, _apply_operation, measurement, _get_measurement_function, expval, var, _local_expectation in the DefaultTensor class. In the original implementation, all these methods were implemented on a separate QuimbMPS class, which I prefer as it creates a stronger separation of responsibilities. Moreover, I think it would make more sense as I believe that such a separation will become more necessary for readability once we start adding exact TN functionality.

[albi3ro]

Sorry about this, but for all the side-effect-style methods, can we add a section to the docstrings:

Side Effect:
     ``self._circuit_MPS`` is updated to include the inputted operator

I know "Side Effect" isn't an official sphinx thing, but I think this would dramatically improve maintainability we start to include it in places like this.

[PietropaoloFrisoni]

@mudit2812 As discussed before, I'm creating a story to eventually move some functions in separate files in the next epic (when the time to implement the remaining method comes).

@albi3ro Yep, I'll add that in the PR implementing the documentation for default.tensor, which still requires additional work.

[albi3ro]

👍 Thanks for addressing my comments. It's an approval from me :)