unitary operator for x.ctrl uses different ordering of qubits in the`register_operation` and the unitary matrix listed in docs is incorrect, also uses inconsistent ordering

Required prerequisites

• Consult the security policy. If reporting a security vulnerability, do not report the bug using this form. Use the process described in the policy to report the issue.
• Make sure you've read the documentation. Your issue may be addressed there.
• Search the issue tracker to verify that this hasn't already been reported. +1 or comment there if it has.
• If possible, make a PR with a failing test to give us a starting point to work on!

Describe the bug

CUDA-Q uses the ordering 00, 10, 01, 11 when printing out the amplitudes using the get_state command. Therefore the unitary matrix for the x.ctrl should be:
$$\begin{pmatrix} 1 & 0 & 0 & 0 \ 0 & 0 & 0 & 1 \ 0 & 0 & 1 & 0 \ 0 & 1 & 0 & 0 \end{pmatrix}$$

The ordering is displayed in docs instead (see screenshot).

The CNOT matrix as shown in the screenshot applied to | + 0 > = [ 1 0 0 1] would output [1 0 1 0] which is | 0 0 > + | 0 1 > which is incorrect for CNOT.
(amplitudes suppressed)

Steps to reproduce the bug

view webpage and carry out the matrix multiplication to see that the unitary is incorrect when applied to the state ()

Expected behavior

ordering of qubits preserved throughout the exposition

Is this a regression? If it is, put the last known working version (or commit) here.

Not a regression

Environment

• CUDA Quantum version: any
• Python version:
• C++ compiler:
• Operating system:

Suggestions

Start with the default_ops.html page and compare its x.ctrl matrix with the ordering used by get_state and register_operation. Check the CNOT example against the stated convention, then make the relevant documentation or operation definition consistent and verify the matrix multiplication.