more generic broadcast for AbstractBlockTuple

[ogauthe]

This PR generalizes broadcast for AbstractBlockTuple. It allows broadcast between an AbstractBlockTuple and

• another AbstractBlockTuple with same total length but different blocklengths
• a Tuple with same length
• a scalar
• an AbstractVector with same length

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.43%. Comparing base (db42098) to head (109db15).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #46      +/-   ##
==========================================
+ Coverage   95.18%   95.43%   +0.25%     
==========================================
  Files          14       14              
  Lines         415      438      +23     
==========================================
+ Hits          395      418      +23     
  Misses         20       20              

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]

Looks great, looks like a nice implementation of combining the block structures. Ready to merge?

[ogauthe]

Not yet, I took a shortcut for the 2nd type parameter. I need to fix BlockedPermutation .+ BlockedTuple.

[ogauthe]

• I fixed the 2nd type parameter, there may be more elegant ways of doing it.
• To be consistent, broadcasting with a tuple now also preserves blocking.
• there seems to be no way of preserving type stability when broadcasting with a vector.
  One would first need to define

Base.Broadcast.axistype(::Base.OneTo, b::BlockedOneTo) = b
Base.Broadcast.axistype(b::BlockedOneTo, ::Base.OneTo, ) = b

in BlockArrays.jl, even after this there are issues deep inside broadcasting internals. I think it is not worth trying to enforce type stability here. We may remove the associated @test_broken.

[mtfishman]

I think this looks reasonable for now. Ready to merge?