feat: msm spawn more go routines if scalar contain small values for first chunk

[gbotrel]

In few instances, inputs to the msm (MultiExp) may have a significant number of 0 and 1.

For large instances, the cost of filtering these values is high since we must allocate large area of memory and copy.

Zeroes are not too costly, and in practice we don't seem to suffer from high number of branch misprediction. Each go routine processing a chunk of bit is going to test the digit it gets, if it's zero, it does nothing (and all the other go routines running at the same time do nothing too, since all the digits are 0).

However, "1" values means the first go routine (processing the c lower bits of the scalars) is going to do more work that the other go routines (who only hit "0" digits).

To workaround since (avoiding memory copy); we count the number of scalar where only the c-lowest bits are set. If this represent more than 10% of the total msm instance, we spawn 2 go routines (and process half of the scalars in each) for the msm.

This is likely not an optimal solution and we may iterate to improve complexity for all cases since:

• we now allocate 1 extra set of buckets
• the way we determine c, the size of the bit-window could change if we took into account these small values and the zeroes.

However, in practice, it allows the msm instance in such cases to finish faster, since most of the go routines will finish at the same time.

[yelhousni]

LGTM, the choice of C is not theoretically optimal but in practice this leads to nice speedups especially when there are many 1 scalars.