feat(integer): Adds bitslice operation

[nsarlin-zama]

closes: https://github.com/zama-ai/tfhe-rs-internal/issues/640

PR content/description

Adds a bitslice operation to the integer API. This operation extracts a range of bits from an integer. On native rust integers, this is roughly equivalent to the following operation:

fn bitslice(val: u64, start_bit: usize, end_bit: usize)  -> u64 {
    (val % (1 << end_bit)) >> start_bit
}

On FHE radix integers, we have different cases based on the alignment of the slice bounds w.r.t the block size:

• If start_bit is block aligned, we can simply copy full blocks until we are left with fewer bits than the block size
• If start_bit is not aligned, we have to create blocks by "merging" higher bits from a block and lower bits from its successor. This is done using PBS with bivariate LUTs (one per block).
• In both cases, if the slice size is not block aligned, we have to do one last PBS to create the last block.

The returned ciphertext is filled with 0-trivial ciphertexts to match the input ciphertext size.

Check-list:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)
• Relevant issues are marked as resolved/closed, related issues are linked in the description
• Check for breaking changes (including serialization changes) and add them to commit message following the conventional commit specification

[nsarlin-zama]

Some questions:

• The operations are called scalar_bitslice because the range parameters are cleartexts, and we could technically add support for encrypted ranges later. Does it make sense ? Or should I call them just bitslice because there is no encrypted version ?
• This is only implemented for unsigned integers. We could technically create a version where the sign is kept but I find this more confusing, would this be usefull ?

[tmontaigu]

• The operations are called scalar_bitslice because the range parameters are cleartexts, and we could technically add support for encrypted ranges later. Does it make sense ? Or should I call them just bitslice because there is no encrypted version ?

scalar_bitslice is good as as you said, we may add the encrypted version later