parrec/minc1 don't subclass ArrayProxy

[rmarkello]

While looking at #833 I noticed that neither PARRECArrayProxy nor MincImageArrayProxy subclass ArrayProxy despite there being considerable overlap in their functionality and structure. It seems like it would be reasonable to modify both classes such that they directly inherit from ArrayProxy to reduce duplication of some methods / doc-strings and make them a bit easier to keep in-line with ArrayProxy functionality. (Though I hope there's not a whole lot more changes coming to ArrayProxy in the near future.)

To be fair, based on my understanding neither parrec nor minc1 are widely used formats anymore, so this would be a relatively low-impact change for what could be a headache of a PR. Still, figured I'd bring it up for discussion and see what people thought. I'd be happy to try my hand at this in the coming weeks, if there's interest.

[matthew-brett]

I seem to remember I made a deliberate decision not to sub-class. The array proxy was always meant to be an API, so it made sense for different classes to implement the API. On the other hand it's perfectly possible that led to some code-duplication. If there is some, that would be cleaned up by a PR, it would be worth giving a shot. Maybe just do the basic stuff to see what it looks like?

[effigies]

There are optional parts of the API, so perhaps it would make more sense to abstract out the mandatory parts into a(n abstract?) base class?

Some scale and some don't, so that might be a sensible branch in the hierarchy.

I suspect a large part of the duplication was added in #833, so this may only just now be starting to be worth it.