Adds an abstract type to NamedArrayPartition

[htsnowden]

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

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

Additional context

[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?