Modification of MultiIndexedHitContainer offsets managing and access

This MR is related to the discussion here : !750 (merged)
I added the suggested assert, thanks @rquaglia and @graven to point out these issues

I also change the sort and offsets layout inside MultiIndexedHitContainer

the input of the sort is as follows for plane code (m_ids) and hits related :
1 1 1 ... 0 0 0 ... 3 3 3 ... 2 2 2 ... 23 23 23 ... 22 22 22
swapped two by two

the contiguous vector of ft hits is like that :
hits of plane 1
hits of plane 0
hits of plane 3
hits of plane 2

(an assert was added to be sure we have this type of input, so if scifi numbering is going to change, we will have to swap to the generic range v3 sort used for UT Hits)

I do the sort by lower x inside each range of plane's hits as before,
but now I don't do the sort giving hits sorted by plane on the contiguous vector, I keep the initial order ( 1 0 3 2 5 4 ...) and adapt offsets agencement and access of hits, it seems to be no problematic since pattern recognition just want ft hits sorted by x for each zone and is agnostic of the behind storage thanks to the abstraction put by PrFTHitHandler. The gain seems to be around ~25% - according to callgrind - compared to the initial way with ranges::v3 sort

left: before (initial version with rv3 sort) ; right: after

callgrind files : ftbefore.cg ftafter.cg