Without lifetime tracking, ranges pose a number of issues with regards
to memory safety - use openArray instead which is limited but safe.
In its present form, ranges take a copy of whatever is passed to them
which obscures the copies that they take, leading to misleading and slow
code.
If openArray is not applicable, simply do a seq copy - it's fine and
really doesn't matter in 95% of all cases, then profile and use other
techniques where needed.
* The bit procs defined over number values and openarray are now part of
the bitops2 module and use the more traditional LittleEndian indexing.
* Added BitSeq and BitArray types as defined in the ETH2 spec.
As much as I believe in the power of optimizing compilers, it turned
out that the use of forced inlining with templates still creates a
significant difference in the release builds of nim-faststreams.
Jacek Sieka
Zahary Karadjov