Use an array for `kpo.KPO.KPDT` and other data attributes?

[vandalt]

Hello!

The data attributes of KPO objects, such as KPDT, are usually lists of arrays. I was wondering if it would be OK to use numpy arrays directly for these data structure. I think the conversion overhead will be minimal and it will make these data structures much easier to maninpulate, slice and explore for end users.

I'd be happy to send a PR for this, after #6 gets merged (to avoid merge conflicts).

Thank you!

[vandalt]

One thing I did not think of beforehand is that this would prevent having multiple cubes with different number of integrations in the same KPO.

To me this seems like a reasonable compromise: a single KPO would represent a dataset, and if one wants to extract multiple cubes they can always copy the KPO and extract the other dataset in the new KPO. But if you have a common use-case in mind for heterogeneous dataset, then it is best to keep the list format.

On the other hand, enforcing uniformity could be a good thing, making code that interacts with KPOs easier to write and maintain. This would also be an occasion to uniformize the number of dimensions between cube and frame extraction, and follow the shape of the KPFITS specification at all times.

Let me know what you think @fmartinache.