Docstrings construct QuantumTape via initialization instead of queuing

[albi3ro]

This PR updates the documentation for our circuit representation QuantumTape to reflect the recommended way of constructing the circuit object.

This change has a range of benefits:

Showing external power users how to construct QuantumTape directly upon initialization

Direct construction avoids the black magic and confusion that occurs with the queuing system. WIth direct construction, what the programmer provides upon initialization is exactly what is in the circuit. The programmer doesn't have to worry about removing a given operation. For example, the circuit could contain both op and adjoint(op).

Direct construction allows the same operation to be used multiple times in a circuit:

op = qml.PauliX(0)
QuantumTape([op, op, op])

It also allows the same operations or measurements to be used in multiple different circuits:

ops = [qml.PauliX(0), qml.S(1)]
tape1 = QuantumTape(ops, [qml.expval(qml.PauliZ(0))])
tape2 = QuantumTape(ops, [qml.expval(qml.PauliX(0))])

Unifying documentation and source code practices

Right now, our documentation demonstrates a different way of doing things than implement in our source code. Our source code and tests never keep around an AnnotatedQueue object after program capture. We always capture the program in an AnnotatedQueue, and then construct a circuit object (QuantumScript) via initialization. This allows us to directly control what is going into the circuit, not carry around information we don't need anymore, and leave the circuit (mostly) untouched after initialization.

Since external power users, external developers, and new developers do not know that we do something completely different in source code, this leads to confusion and new code that goes against our desired best practices.

By having the documentation reflect our recommend best practices, it will help new developers understand how we want to actually write code.

Freeing up required future changes to PennyLane

Since this documentation change gets power users familiar with the "construction upon initialization" syntax, it frees us up to remove AnnotatedQueue from QuantumTape in the future. This change will be required to make QuantumTape immutable.

Immutability will forbid certain classes of bugs, allow QuantumTape to better function in a distributed system, improve integration with jax and other machine learning libraries, and open up performance improvements with caching.

By making our circuit representation independent of queuing, we also make anything that relies on QuantumTape robust to changes to how we perform circuit capture. When we change our user interface and how we capture user circuits, these docstrings should still be valid.

[codecov]

Codecov Report

Merging #4243 (474f343) into master (8a75abd) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #4243   +/-   ##
=======================================
  Coverage   99.78%   99.78%           
=======================================
  Files         352      352           
  Lines       31733    31733           
=======================================
  Hits        31665    31665           
  Misses         68       68           

Impacted Files	Coverage Δ
pennylane/drawer/tape_mpl.py	100.00% <ø> (ø)
pennylane/drawer/tape_text.py	100.00% <ø> (ø)
pennylane/gradients/__init__.py	100.00% <ø> (ø)
pennylane/gradients/finite_difference.py	99.45% <ø> (ø)
pennylane/gradients/hadamard_gradient.py	100.00% <ø> (ø)
pennylane/gradients/jvp.py	100.00% <ø> (ø)
pennylane/gradients/parameter_shift.py	100.00% <ø> (ø)
pennylane/gradients/parameter_shift_cv.py	99.61% <ø> (ø)
pennylane/gradients/spsa_gradient.py	100.00% <ø> (ø)
pennylane/gradients/vjp.py	100.00% <ø> (ø)
... and 19 more

[timmysilv]

exciting stuff!

[trbromley]

Overall sounds good! 👍

[mudit2812]

Formatting suggestions, but otherwise looks good to go 😄