Normally creating a custom gate class that overloads the name of a
Qiskit defined operation is not valid and not allowed. The names have
meaning and are often used as identifiers and this overloading the name
will prevent Qiskit from correctly identifying an operation. However as
was discovered in #14103 there are some paths available around
serialization and I/O where Qiskit does this itself. For example, qasm
(both 2 and 3) is a lossy serialization format and qasm2 doesn't have a
representation of a UnitaryGate. So when the qasm2 exporter encounteres
a `UnitaryGate` it is serialized as a custom gate definition with the
name "unitary" in the output qasm2 and the definition is a decomposition
of the unitary from the `UnitaryGate`. When that qasm2 program is
subsequently deserialized by qiskit parser the custom gate named "unitary"
is added as a `_DefinedGate` subclass which includes an `__array__`
implementation which computes the unitary from the definition using
the quantum info Operator class. This makes the custom gate parsed from
qasm2 look like a `UnitaryGate` despite not actually one so this is
typically fine for most use cases. However, since #13759 trying to add
that not `UnitaryGate` object named "unitary" would cause the Python ->
Rust translation to panic (which happens as part of qasm2
desierailzation). because the conversion was expecting a gate named
`unitary` to be a `UnitaryGate` as is prescribed by the data model.

This commit fixes this by gracefully handling the lack of a matrix
parameter as it not actually being a `UnitaryGate` and instead the
object gets treated as a `PyGate` in rust which is the expected
behavior.

Related to #14103

(cherry picked from commit ddb8025)

# Conflicts:
#	crates/circuit/src/circuit_instruction.rs
#	test/python/transpiler/test_split_2q_unitaries.py

Normally creating a custom gate class that overloads the name of a
Qiskit defined operation is not valid and not allowed. The names have
meaning and are often used as identifiers and this overloading the name
will prevent Qiskit from correctly identifying an operation. However as
was discovered in #14103 there are some paths available around
serialization and I/O where Qiskit does this itself. For example, qasm
(both 2 and 3) is a lossy serialization format and qasm2 doesn't have a
representation of a UnitaryGate. So when the qasm2 exporter encounteres
a `UnitaryGate` it is serialized as a custom gate definition with the
name "unitary" in the output qasm2 and the definition is a decomposition
of the unitary from the `UnitaryGate`. When that qasm2 program is
subsequently deserialized by qiskit parser the custom gate named "unitary"
is added as a `_DefinedGate` subclass which includes an `__array__`
implementation which computes the unitary from the definition using
the quantum info Operator class. This makes the custom gate parsed from
qasm2 look like a `UnitaryGate` despite not actually one so this is
typically fine for most use cases. However, since #13759 trying to add
that not `UnitaryGate` object named "unitary" would cause the Python ->
Rust translation to panic (which happens as part of qasm2
desierailzation). because the conversion was expecting a gate named
`unitary` to be a `UnitaryGate` as is prescribed by the data model.

This commit fixes this by gracefully handling the lack of a matrix
parameter as it not actually being a `UnitaryGate` and instead the
object gets treated as a `PyGate` in rust which is the expected
behavior.

Related to #14103

(cherry picked from commit ddb8025)

Normally creating a custom gate class that overloads the name of a
Qiskit defined operation is not valid and not allowed. The names have
meaning and are often used as identifiers and this overloading the name
will prevent Qiskit from correctly identifying an operation. However as
was discovered in #14103 there are some paths available around
serialization and I/O where Qiskit does this itself. For example, qasm
(both 2 and 3) is a lossy serialization format and qasm2 doesn't have a
representation of a UnitaryGate. So when the qasm2 exporter encounteres
a `UnitaryGate` it is serialized as a custom gate definition with the
name "unitary" in the output qasm2 and the definition is a decomposition
of the unitary from the `UnitaryGate`. When that qasm2 program is
subsequently deserialized by qiskit parser the custom gate named "unitary"
is added as a `_DefinedGate` subclass which includes an `__array__`
implementation which computes the unitary from the definition using
the quantum info Operator class. This makes the custom gate parsed from
qasm2 look like a `UnitaryGate` despite not actually one so this is
typically fine for most use cases. However, since #13759 trying to add
that not `UnitaryGate` object named "unitary" would cause the Python ->
Rust translation to panic (which happens as part of qasm2
desierailzation). because the conversion was expecting a gate named
`unitary` to be a `UnitaryGate` as is prescribed by the data model.

This commit fixes this by gracefully handling the lack of a matrix
parameter as it not actually being a `UnitaryGate` and instead the
object gets treated as a `PyGate` in rust which is the expected
behavior.

Related to #14103

(cherry picked from commit ddb8025)

Co-authored-by: Matthew Treinish <mtreinish@kortar.org>