avoid unnecessary copy in setXLen

[pietroppeter]

the fix for #27 done in #35 introduced a copy in setXLen that has some impact in the performance in some cases (see benchmark on chainAddition in this comment).
In principle it is possible to fix the issue in self addition without introducing a new copy but it requires more effort.

Note that legacy usage of setXLen remains accessible through a compile time switch bigintsLegacySetXLen.

[pietroppeter]

not relevant anymore given the recent merge (#40).