Support spare Prepare with log_block_size=0

[mpharrigan]

Fixes #1547

PrepareSparse would fail to decompose with log_block_size=0, which is extra unfortunate since the automatic-block-size determination would choose this sometimes. It looks like SelectSwapQROM and QROAMClean support log_block_size=0, but I'd really love if @tanujkhattar or @fdmalone could give a second opinion. The bug fix itself is entirely within PrepareSparse -- better accounting of the qroam registers.

Some drive-by doc formatting fixes as well

[tanujkhattar]

Looks good, thanks! Your analysis is correct that the qrom bloqs should support log_block_size=0, and if they don't then that's a bug that should be fixed.

[tanujkhattar]

We could also write this in a way that we use the extra registers defined in self.build_qrom_bloq.signature and return them here directly, or we could assert what we expect the shapes of those registers to be and then raise a value error if that's not the case, to find such bugs earlier.

[mpharrigan]

ah I think I see what you're saying. I'm going to merge as-is for expediency and open an issue

[tanujkhattar]

To confirm, this was always a bug and the consistency between build_call_graph and build_composite_bloq was not tested and is now fixed? Or is this because we are now supporting log_block_size=0 ?

[mpharrigan]

test_decompose_bloq_counts was written in a brittle way that broke when I changed the test example to use the default block size, which is zero for the bloq example. I changed it to use the familiar qlt_testing.assert_equivalent_bloq_counts which revealed that: yes, the CZs were missing from the call graph and should be there