Redefine blocksizes

[mtfishman]

This is a first pass at #369, as discussed in #255.

To-do:

• Full test coverage.
• Add documentation.

Some questions to discuss:

• Should BlockSizes be a subtype of AbstractArray? In the latest, I didn't go that route and instead implemented the iterator interface. My reasoning was that it is not obvious what eltype should be for arbitrary block arrays, and even within block arrays the types of the sizes of different blocks could be different. EDIT: In the latest, BlockSizes <: AbstractArray with a concrete element type based on eltype.(axes(array)).
• The current design computes the block size of a block using the size of the view of that block. Is that a good definition, or is it better to get the block sizes from the axes? EDIT: Will keep that design for now and analyze the performance in future PRs.
• How should printing be handled? It would be nice for it to print like an n-dimensional array but I don't know of a simple way to make use of AbstractArray printing without reaching into Julia Base internals. One strategy I was trying was to make another type BlockSizesArray which is like BlockSizes but is an AbstractArray subtype, that works ok but then I don't know how to customize printing the type. EDIT: Now it is handled automatically because BlockSizes <: AbstractArray.
• Should we define blocksizes(a::AbstractArray, d::Integer) = blocklengths(axes(a, d))? That would actually bring back the previous definition of blocksizes(a::AbstractArray, d::Integer). EDIT: Implemented in the latest.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.59%. Comparing base (6502fad) to head (e56ca07).
Report is 97 commits behind head on release-1.0.

Additional details and impacted files

@@               Coverage Diff                @@
##           release-1.0     #399       +/-   ##
================================================
+ Coverage         0.00%   95.59%   +95.59%     
================================================
  Files               16       18        +2     
  Lines             1462     1522       +60     
================================================
+ Hits                 0     1455     +1455     
+ Misses            1462       67     -1395     

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

[mtfishman]

@jishnub @dlfivefifty I think this is ready to review. I listed a few design questions to discuss in the first post.

Seems like the downstream tests pass, I guess they weren't using the previous blocksizes(...) definition.

[dlfivefifty]

Should BlockSizes be a subtype of AbstractArray? In the latest, I didn't go that route and instead implemented the iterator interface. My reasoning was that it is not obvious what eltype should be for arbitrary block arrays, and even within block arrays the types of the sizes of different blocks could be different

Can't we infer the type of the block sizes from the axes? This would fix the printing.

The current design computes the block size of a block using the size of the view of that block. Is that a good definition, or is it better to get the block sizes from the axes?

I suspect using axes is better but this is an optimisation detail that can be changed later.

Should we define blocksizes(a::AbstractArray, d::Integer) = blocklengths(axes(a, d))? That would actually bring back the previous definition of blocksizes(a::AbstractArray, d::Integer).

Sure

[mtfishman]

Thanks for the feedback @dlfivefifty, I will update the PR this week reflecting your suggestions.

[mtfishman]

@dlfivefifty I believe I've addressed all of your comments and the open issues I listed in the first post.