Adds an abstract type to NamedArrayPartition

[Snowd1n]

In order to resolve #443 where I would like to be able to subtype from NamedArrayPartition. This is a large restructuring of NamedArrayPartition but all tests within RecursiveArrayTools do pass. I'm not sure of other tests that I would need to run to ensure further compatibility. This maintains all current functionality but allows a user to create a new subtype of AbstractNamedArrayPartition as long as it maintains the same structure. I am pulling into this branch as this is where my previous fix to the ArrayInterface.zeromatrix lives.

Checklist

• Appropriate tests were added
• Any code changes were done in a way that does not break public API
• All documentation related to code changes were updated
• The new code follows the
  contributor guidelines, in particular the SciML Style Guide and
  COLPRAC.
• Any new documentation only uses public API

Additional context

[ChrisRackauckas]

I think this should have an AbstractArrayPartition, and that needs a docstring to describe its interface?

[ChrisRackauckas]

Or is ArrayPartition an AbstractNamedArrayPartition with x being its only names?

[Snowd1n]

I can add a higher level called AbstractArrayPartition{T} if you want and apply the same level of abstraction to the ArrayPartition interface as well (either or both) such that the same subtyping can be performed there also. I will add to the documentation, a docstring about how you can subtype from the AbstractNamedArrayPartition

[ChrisRackauckas]

Why is this one commented?

[Snowd1n]

Because I couldn't manage in either the old or the new method to call the less specific function as providing an NamedArrayPartition will have the type structure X{N, A, NT} and therefore a later version would have instead been called. In the original code the two functions are:

function Base.similar(A::NamedArrayPartition)
    NamedArrayPartition(
        similar(getfield(A, :array_partition)), getfield(A, :names_to_indices))
end

function Base.similar(x::NamedArrayPartition{T, S, NT}) where {T, S, NT}
    NamedArrayPartition{T, S, NT}(
        similar(ArrayPartition(x)), getfield(x, :names_to_indices))
end

But in all cases I tested the second always overwrites the first as any NamedArrayPartition has the structure of the second

[ChrisRackauckas]

It's still missing what is meant by the interface. See for example https://github.com/SciML/RecursiveArrayTools.jl/blob/master/src/RecursiveArrayTools.jl#L16-L110. The questions that have to be answered are:

1. What does it mean to be an AbstractNamedArrayPartition / AbstractArrayPartition? What things must be true about the definition in order to satisfy the interface? For example, is there a allowednames function or something that everything should assume exists for AbstractNamedArrayPartition
2. What are the functions and allowed operations on any member of this group?
3. What is the relation to any other interface (for example AbstractArray)?

Then we need to make sure the abstract library implementations actually match this. For example, for ArrayPartition, the code currently always assumes A.x. See a chunk like https://github.com/SciML/RecursiveArrayTools.jl/blob/master/src/array_partition.jl#L127-L177. So there's a few decisions that have to be made here:

1. Is ArrayPartition <: AbstractNamedArrayPartition where the names are just x?
   • If that's the case, then we probably need to generalize those functions I linked to so that they match the interface, rather than being specific to ArrayPartition. Seems like a lot of code code could be deleted.
2. Are AbstractNamedArrayPartition expected to be non-allocating if they .=?
3. How is AbstractNamedArrayPartition expected to interact with LinearAlgebra?