[WIP] Define random_unitary constructor

[mtfishman]

Depends on ITensor/BlockSparseArrays.jl#85.

@lkdvos I've introduced a qr_positive constructor for matrices but we should probably have a tensor version too, related to the new factorization you introduced in #36.

The motivation for this is defining a more general "RandomUnitary" gate in https://github.com/ITensor/QuantumOperatorDefinitions.jl that will handle symmetries.

To-do:

• Add tests.
• Merge and register [WIP] Define zeros for graded unit ranges BlockSparseArrays.jl#85, or wait for moving that to a new GradedArrays.jl package. Not needed in the latest version.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 36 lines in your changes missing coverage. Please review.

Project coverage is 87.55%. Comparing base (28577a3) to head (879ef7d).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/random_unitary.jl	0.00%	28 Missing ⚠️
...nsorAlgebraBlockSparseArraysGradedUnitRangesExt.jl	0.00%	8 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #39      +/-   ##
==========================================
- Coverage   95.02%   87.55%   -7.47%     
==========================================
  Files          15       17       +2     
  Lines         422      458      +36     
==========================================
  Hits          401      401              
- Misses         21       57      +36     

Flag	Coverage Δ
docs	0.00% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mtfishman]

It's also possible TensorAlgebra.jl isn't the right place to define constructors like this, but I don't know where else they would be defined...

[mtfishman]

Note that the package extension organization and names can be simplified once we change over GradedUnitRanges.jl to GradedArrays.jl.

[mtfishman]

@lkdvos this is ready for another look, I'm curious what you think of the latest design.

[lkdvos]

I think this looks quite clean, it seems like you managed to decouple quite a lot of the dependencies this way

[lkdvos]

Something worth considering: in this function we are not guaranteed the user inputted a square matrix, in which case this function would still work, but spit out a random left- or right- isometry. I think if we call the function unitary, we probably want to check for this, either by an explicit checksquare, or some other means.

[mtfishman]

Good point, I had that in mind but forgot to add that check. We should definitely check it is square (and more specifically, the blocks are the same and the codomain is the dual of the domain).

[mtfishman]

The idea is definitely that it is unitary in a strict sense, in that it literally maps the space back to itself.

[mtfishman]

After adding this check, I realized there is a crucial thing missing from this PR, which is specifying that the codomain and domain are duals of each other. That will require a separate PR to fusedims to support that, though @ogauthe is reworking fusedims/splitdims to accommodate FusionTensors so I'll hold off on that for now.