chore: using fhe.bits() feature in Game of Life example

[bcm-at-zama]

Testing fhe.bits() within Game of Life

[bcm-at-zama]

Don't merge now, I see strange performances (it's slower than the other cases, like 5b method, I don't understand why). I'll open issues about the perf

[bcm-at-zama]

Related to https://github.com/zama-ai/concrete-internal/issues/557

[bcm-at-zama]

Turns out the perf are expected, we'll explain it in the doc as clearly as possible:

fhe.bits()[i] is not the same depending on the i. The smaller the i, the faster.

More or less, under the hood, an fhe.bits()[3] will be replaced by a code like

    %3 = "FHELinalg.sub_int_eint"(%from_elements, %inserted_slice) : (tensor<1xi5>, tensor<1x1x10x10x!FHE.eint<4>>) -> tensor<1x1x10x10x!FHE.eint<4>>
    %4 = "FHELinalg.lsb"(%3) : (tensor<1x1x10x10x!FHE.eint<4>>) -> tensor<1x1x10x10x!FHE.eint<4>>
    %5 = "FHELinalg.sub_eint"(%3, %4) : (tensor<1x1x10x10x!FHE.eint<4>>, tensor<1x1x10x10x!FHE.eint<4>>) -> tensor<1x1x10x10x!FHE.eint<4>>
    %6 = "FHELinalg.reinterpret_precision"(%5) : (tensor<1x1x10x10x!FHE.eint<4>>) -> tensor<1x1x10x10x!FHE.eint<3>>
    %7 = "FHELinalg.lsb"(%6) : (tensor<1x1x10x10x!FHE.eint<3>>) -> tensor<1x1x10x10x!FHE.eint<3>>
    %8 = "FHELinalg.sub_eint"(%6, %7) : (tensor<1x1x10x10x!FHE.eint<3>>, tensor<1x1x10x10x!FHE.eint<3>>) -> tensor<1x1x10x10x!FHE.eint<3>>
    %9 = "FHELinalg.reinterpret_precision"(%8) : (tensor<1x1x10x10x!FHE.eint<3>>) -> tensor<1x1x10x10x!FHE.eint<2>>
    %10 = "FHELinalg.lsb"(%9) : (tensor<1x1x10x10x!FHE.eint<2>>) -> tensor<1x1x10x10x!FHE.eint<2>>
    %11 = "FHELinalg.sub_eint"(%9, %10) : (tensor<1x1x10x10x!FHE.eint<2>>, tensor<1x1x10x10x!FHE.eint<2>>) -> tensor<1x1x10x10x!FHE.eint<2>>
    %12 = "FHELinalg.reinterpret_precision"(%11) : (tensor<1x1x10x10x!FHE.eint<2>>) -> tensor<1x1x10x10x!FHE.eint<1>>
    %13 = "FHELinalg.apply_lookup_table"(%12, %cst) : (tensor<1x1x10x10x!FHE.eint<1>>, tensor<2xi64>) -> tensor<1x1x10x10x!FHE.eint<4>>
with 3 calls to lsb and one call to apply_lookup_table. A call to lsb is more or less as costly as an 1b PBS.

So:

for large bitwidth or for small i, fhe.bits()[i] may be very useful
but when the bitwidth is not that large, or i is not that small, it may be more costly.

[bcm-at-zama]

I think this PR is still interesting to merge, it's a good example of fhe.bits