Make Operator.data a tuple instead of a list

[eddddddy]

Context:
Part of the ongoing effort towards operator immutability.

Description of the Change:
Make Operator.data a tuple instead of a list. Change everywhere Operator.data is used to expect a tuple instead of a list.

[github-actions]

Hello. You may have forgotten to update the changelog!
Please edit doc/releases/changelog-dev.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

Merging #4222 (8dcca47) into master (1c5e44b) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #4222   +/-   ##
=======================================
  Coverage   99.78%   99.78%           
=======================================
  Files         352      352           
  Lines       31741    31754   +13     
=======================================
+ Hits        31673    31686   +13     
  Misses         68       68           

Impacted Files	Coverage Δ
pennylane/ops/op_math/adjoint.py	100.00% <ø> (ø)
pennylane/ops/op_math/controlled.py	100.00% <ø> (ø)
pennylane/operation.py	97.33% <100.00%> (+0.01%)	⬆️
pennylane/ops/op_math/composite.py	100.00% <100.00%> (ø)
pennylane/ops/op_math/evolution.py	100.00% <100.00%> (ø)
pennylane/ops/op_math/symbolicop.py	100.00% <100.00%> (ø)
pennylane/ops/qubit/hamiltonian.py	100.00% <100.00%> (ø)
pennylane/optimize/adaptive.py	100.00% <100.00%> (ø)
pennylane/tape/qscript.py	99.04% <100.00%> (+0.01%)	⬆️

[mudit2812]

Thanks for the changes @eddddddy ! I'm hesitant about the changes to QuantumScript._par_info, but apart from that, this PR looks good :)

[timmysilv]

are we going to remove data setters soon? I was going to ask if we should update the setters in various files (evolution.py, pow.py and symbolicop.py) to cast the inputted new_data as tuples before setting it, but I realize we'd probably rather just delete the setters altogether!

Keen to approve, but very hesitant about the _par_info/get_operation change. I don't want to block this PR because a problem with QuantumScript, but perhaps a bit more clarity on direction first

[mudit2812]

are we going to remove data setters soon? I was going to ask if we should update the setters in various files (evolution.py, pow.py and symbolicop.py) to cast the inputted new_data as tuples before setting it, but I realize we'd probably rather just delete the setters altogether!

The intention is to start using bind_new_parameters to replace the use of data setters and entirely move away from in-place mutation of operators. Changes towards this are already being made (eg. #4220)

[eddddddy]

Do we want to remove the setters in this PR or a follow-up one?

[mudit2812]

Do we want to remove the setters in this PR or a follow-up one?

@albi3ro can confirm, but I'd imagine a follow-up one. It's a pretty major breaking change so it would likely need a deprecation cycle.

[timmysilv]

definitely don't remove in this PR - if there was anything to do in this one, it would be to add casting to tuple in existing data setters, but I'm ok to just leave them be. tl;dr nothing to do here 😄

[timmysilv]

last comment, otherwise lgtm and I will approve:)

[mudit2812]

Thanks @eddddddy !

[eddddddy]

[sc-36757]