WIP: Proposal to structure dense indexer classes

[pfs]

The idea is that each indexer class holds the following items

• an enum corresponding to the typecodes or a sequence of typecodes expected
• the list of dense indexers required to optimally pack each typecode
• an offset corresponding to each typecode

[pfs]

@kerstinlovisa

[kerstinlovisa]

@pfs I'll need to make some changes again to handle the new typecodes for the silicon cells. So just checking: should I translate the typecode to the type numbering we had before type ={0:'F', 1:'T', 2:'B', 3:'L', 4:'R', 5:'5'} for the SoA to avoid storing the string values?

[pfs]

@kerstinlovisa thanks, we can add such decoding utility indeed. But I would propose to keep the internal mapping with the typecode string as is. The classes will know which final index corresponds to each unique typecode without need to really know what it means.