Fix orbit packaging with last BXs of previous orbits in current orbit using aligner logic

Addressing #90 (This might be my xmas gift to the scouting fw (if the idea really works)).

This issue, that causes headaches in the CMSSW processing part (and not only), might be solved in a smart way by letting the bx_aware_aligner become a orbit_and_bx_aware_aligner. Namely:

• when we start reading an orbit from the small fifos in the aligner, we start with the HEADER and then with BX 3555
• this means we expect BXs [3555, 3564] after the HEADER, so we can:
• ...latch the header frame when we get it
• ...let the aligner count the BXs
• ...when we are at BX 3564, we mark this BX with a LAST bit
• ...then we let the aligner output dummy frames which are actually a reserved space to place a trailer as long as we want (but with a reasonable size of < 20 frames)
• ...we output also a placeholder for the packet trailer
• ...we output a placeholder for the new header frame, which we fill with the header frame that we latched before
• ...we start again with BX 1 -> BX 3554 (same logic)
• ...at BX 3555 the same logic applies

The outcome of this is that we have orbits that are marked with HEADER=1 immediately before BX=1 and with LAST=1 at BX=3564. And after BX=3564 a space of N frames (I put around 18) is granted. We shouldn't be affected by FIFOs filling completely using this approach, because we don't fill the aligner FIFOs with PADDING/COMMA words.

I need to test this in a simulation. Also, I will polish this MR after the xmas break, but I think the idea should work and also it will just require to replace the existing bx_aware_aligner module, remove the bx_counter module and perhaps adapt the module that fills the trailer