How to format big spares matrices in docs.

[dabacon]

As part of #5344 @viathor brought up possibly formatting our sparse matrices in docstring (and hence API docs) with blanks instead of 0s.

So for example we currently format a CNOT as

\begin{bmatrix}
    1 & 0 & 0 & 0 \\
    0 & 1 & 0 & 0 \\
    0 & 0 & 0 & 1 \\
    0 & 0 & 1 & 0
\end{bmatrix}

but we could instead use

\begin{bmatrix}
    1 & & & \\
    & 1 & & \\
    & & 0 & 1 \\
    & & 1 & 0
\end{bmatrix}

or even

\begin{bmatrix}
    1 & & & \\
    & 1 & & \\
    & & & 1 \\
    & & 1 &
\end{bmatrix}

The sparser version does render better in the doc string, and it does render fairly nicely on the documentation site. But I worry a bit that it is confusing to users. I think for people just starting in quantum it might be super confusing.

Current status (after #5344) is that the sparse representation is only used for 3 qubit gates or greater.

Should we use the sparse representation for 2 qubit gates (I think for 1 qubit gates, keeping the zeros parses fine)

[mhucka]

What about this alternative idea: make the color of the 0's be a shade of gray. Example to illustrate what it might look like:

This could be done automatically. If the begin{bmatrix} ... \end{bmatrix} are LaTeX, then this could be done by writing a modified version of the bmatrix macro that detects 0's and does the appropriate coloring automatically so that the author doesn't have to do anything. If that's MathJax, I know there's a way to define custom macros there too, although I'm less certain of how to overwrite the definition of an existing macro.

(Personally I would find it confusing if the 0's were missing altogether, given that pretty much every textbook I've countered so far shows them.)

[mhucka]

Update: I've spent some time studying the feasibility of this. I've worked out how to do it in LaTeX, but after studying the way docs are built for Cirq, it doesn't look like that would be directly useful. It appears there are 2 relevant cases for Cirq:

1. Docs built for websites appear to be generated using Tensorflow's doc generation code, which ultimately uses MathJax for the Math rendering
2. Docs written in Collab use Collab's built-in rendering facility, which also uses MathJax.

Could someone verify that those are the 2 cases, and that I'm not missing something?