Adds kraussop.py that contains interface (base) class.  Adds implementation
of this interface in DenseOperator and DenseUnitaryOperator, which required
adding a 'basis' argument to DenseOperator.__init__.  This update cascaded to
updating several of the DenseOperator subclasses, such as FullArbitraryOp.
'None' is allowed to be specified as the basis, but if so the Kraus op functionality
is unavailable.

…ses.

The big update in this commit is the addition of new OpRepKraus
and OpRepRandomUnitary classes the the densitymx and densitymx_slow
evotypes, and OpRepRandomUnitary to the chp evotype.  The existing
OpRepStochastic class (only in these 3 evotypes) is updated to inherit
from OpRepRandomUnitary and has an updated signature, propagating to
updates in StochasticNoiseOp.

… correct now.

Fixes normalization bugs and adds explanatory comments in DenseOperator.kraus_operations
so that correct Kraus operations are produced.  Previously they were correct up to
normalization.

…raus updates.

Implements KrausOperatorInterface within StochasticNoiseOp by calling
.to_dense() on the unitary_reps within a OpRepRandomUnitary representation.
When this isn't implemented (e.g. CHP evotype) than an error will be raised.
This commit includes other minor updates/fixes to op reps and operator classes.

Implements a default outcome-for-shot method in WeakForwardSimulator
(though this is inefficient when the "shot" actually can compute a
probability distribution rather than a single outcome) that can be
used by the now-augmented 'statevec_slow' evotype.  The statevec_slow
evotype has been augmented with acton_random methods and new
OpRepRandomUnitary and OpRepStochastic classes to allow it to
work with WeakForwardSimulator even with models containing StochasticNoiseOp
operations.

…n. Minor bug fixes.

This allows, in particular, the CHP evotype and forward simulator to be run
on an ExplicitOpModel created from create_explicit_model that has depolarizing
noise (set by the depolarization_strengths arg).  The CHP evotype only supports
standard gates thus far (though it could be expanded to arbitrary Clifford gates)
and so needed the standard name of a gate to be computed correctly during model
construction even when the gate name didn't match a standard name (e.g. the '{idle}'
gate created by an explicit model).

This commit also fixes several other minor bugs introduced in recent commits
related to the new random unitary operator representation objects.

This update makes several related changes that in the end allow the
CHP evotype to be used with WeakForwardSimulator, MapForwardSimulator,
and SimpleMapForwardSimulator forward simulators (the latter two only
work when the circuit is made up of noiseless Clifford ops).

- addition of POVM representation objects.  Evolution types can now
  be asked to generate computational and composed (and in the future
  more?) POVM representations.  The only evotype that currently does
  this is 'chp', but the functionality may prove useful to future
  evotypes.

- ComposedPOVM and CompuationalBasisPOVM attempt to construct POVM
  representations BUT allow the creation call to fail (as it does
  for all but the 'chp' evotype currently) and then set their ._rep
  attribute to None.  Unlike other modelmember types, a POVM *is*
  allowed to have its ._rep == None provided it contains or can
  produce effect objects with valid representations.

- WeakForwardSimulator, MapForwardSimulator, and SimpleMapForwardSimulator
  are updated to prefer to use a POVM's representation to compute
  outcome samples or probabilities, and in the case the ._rep == None
  fall back to computing with effect vectors as before.  This allows the
  chp evotype to interface with these forward sims via its POVM reps
  rather than unnaturally through POVM effect objects & reps.

- the chp evotype contains a new povmreps.py file that holds POVM
  representation classes.  The POVM reps perform the actual running
  of the CHP executable (previously in CHPForwardSimulator) when
  outcome samples or probabilities are requested by a (generic)
  forward simulator.

This update is also meant to provide (& test) a new, hopefully more
natural and efficient paradigm for introducing new third party
circuit simulators to pyGSTi: by adding just a new evotype rather than
an evotype and a new forward simulator.  We'll see how this holds up.

…otype.

Basically translates the Kraus-map and weak-forwardsim supporting functionality
in 'statevec_slow' into 'statevec'.  This is pretty straightforward but does require
calling a Python method from within C code, which is the first example of this in
the codebase.