Require undef in BlockSparseArray constructors

[mtfishman]

Fixes #69. Related to ITensor/SparseArraysBase.jl#33.

This also introduces sparsemortar, which is like BlockArrays.mortar but for constructing a BlockSparseArray.

[codecov]

Codecov Report

Attention: Patch coverage is 90.16393% with 6 lines in your changes missing coverage. Please review.

Project coverage is 75.46%. Comparing base (5c72fbd) to head (74d02d0).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/blocksparsearray/blocksparsearray.jl	87.50%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #68      +/-   ##
==========================================
- Coverage   75.71%   75.46%   -0.25%     
==========================================
  Files          29       28       -1     
  Lines        1083     1072      -11     
==========================================
- Hits          820      809      -11     
  Misses        263      263              

Flag	Coverage Δ
docs	16.39% <27.86%> (-8.95%)	⬇️

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.

[mtfishman]

@lkdvos I'd be curious to get your feedback on this, particularly the name sparsemortar.

[lkdvos]

Overall definitely looks good to me.

I left some comments about the organization of the constructor call chain, but keep in mind that I'm not sure if that structure is standard practice or simply something I have picked up over the years which I have found to be quite robust and stable.
Bottom line, this is a bit subjective anyways, but I do like the clear separation of responsibilities.

Considering the sparsemortar name, I think that's good, and in line with sparserand and sparsezeros so that seems consistent.
I am wondering a bit if we can get away with not having that function at all, and repurposing sparse(mortar(args...)) instead, which is only a few characters longer and reuses functionality we would probably have to have anyways. (in which case we can still define it ofcourse). I don't think it matters too much of course, just wanted to share some thoughts 😉

[mtfishman]

@lkdvos in the latest I:

1. introduced _BlockSparseArray as an inner constructor,
2. deleted versions of BlockSparseArray that accept blocks,
3. deleted sparsemortar(::Dictionary, axes) and also the version that accepted lists of block locations and data, so now there is only sparsemortar(blocks::AbstractArray{<:AbstractArray}, axes), and
4. introduced SparseArrayDOK{Matrix{Float64}}(undef_blocks, [2, 3], [2, 3]) as a helper function for constructing block sparse arrays.

[mtfishman]

@lkdvos I've update the PR based on your last round of comments, this is good to go from my end. Let me know if you have any more comments.

[lkdvos]

We could consider re-exporting that too if it turns out we are using this often

[mtfishman]

Right, that touches on a broader question I've been grappling with about how much we want to re-export things. So far my strategy with these new packages is to be very conservative about what we export, including not re-exporting anything and expecting users to load the packages where the objects originated themselves, but once the dust settles a bit and we start using these packages more I'm open to some targeted re-exports.