A type index fragmentation strategy

[constraintAutomaton]

The ongoing work in Solidbench is to evaluate data summary method/ indexation strategies. In the current implementation, the type index is in transformer, whereas the shape index ( WIP #22) is in the fragmenter strategy. So I wonder if the type index should be moved into the fragmenter or if the shape index should become a transformer, because they are supposed to be similar. One consideration is that for the shape index there can be more variations (shape more or less descriptive, open and close) in its declaration ,we are implementing a way to generate partial ones and we have an option to generate a triple in each file to locate the shape index location, so I am not sure if implementing both has transformer is the better idea and adding the new functionalities to type index (probably having an abstract fragmenter/transformer strategy with a concrete implementation for both) or if both should be fragmentation strategies.

related to #22 and maybe #18

[edited because I realise how the type index is generated]

[rubensworks]

I would not change anything to the type index creation until the need actually exists to change it.