fix(hlapi): rework CompressedCiphertextListBuilder

[tmontaigu]

The hlapi builder target device was selected depending on features (gpu enabled ? gpu : cpu), but if at build time the thread_local key did not match the expected device, an error would be returned.

This is a bit too limiting for users that might want to do some processing on GPU and compression on CPU.

So the Builder is changed to delay, the selection of device used to compress when build is called.
This new design is more flexible for end users, at the cost of a bit more memory copies

• There should be no API breaking change
• There is no serialization breaking change as only the builder
  (which is not serializable) has been changed

[IceTDrinker]

Only one question, otherwise this looks good, though it shows we need to upgrade primitives to use iterators over some types rather than force the WhateverList construct inherited from the previous iteration of the lib

[tmontaigu]

Only one question, otherwise this looks good, though it shows we need to upgrade primitives to use iterators over some types rather than force the WhateverList construct inherited from the previous iteration of the lib

Yeah I sort of considered to do it here, but for this kind of things, it generally we want to iterate twice: once to get the number of lwe to preallocate the glwe_list, and a second time so populate the glwes

[IceTDrinker]

Only one question, otherwise this looks good, though it shows we need to upgrade primitives to use iterators over some types rather than force the WhateverList construct inherited from the previous iteration of the lib

Yeah I sort of considered to do it here, but for this kind of things, it generally we want to iterate twice: once to get the number of lwe to preallocate the glwe_list, and a second time so populate the glwes

otherwise we need primitives to extend a List instead of manipulating the container, you can enhance ContiguousEntityContainerMut if you want to be able to append