feat(translation-worker): add translation worker with argostranslate

[winsomeglint]

Adds a translation worker under translation-worker powered by ctranslate2 and argostranslate.

[ClemDoum]

I feel like these ones could go in here: https://github.com/ICIJ/icij-python/tree/main/icij-common/icij_common
Since there are not datashare / temporal specific but more asyncio / iteratools related utils useful in all icij python projects

[ClemDoum]

I think we should split between the TranslationConfig and TranslationWorkerConfig.
The TranslationConfig should hold all parameters which can be tweaked between calls, it should be filled by the caller/dev while the TranslationWorkerConfig should be created and set bet the person who deploys the worker and can tune parameters according to the actual worker resources.

For some parameters its not trivial to decide but for others it's more straightforward.
I'd say:

• device should be in TranslationWorkerConfig (the worker knows it it's a CPU or GPU worker)
• batch_size / max_parallel_batches it's tempting to put it in the TranslationConfig, but probably more appropriate in the TranslationWorkerConfig. This way we can deploy the same code, but just change the deployments if workers are hitting OOM or are not running at full speed
• beam_size / num_hypotheses should be TranslationConfig since it impact the translation output
• inter_threads / intra_threads / compute_type since to be more worker options than runtime options

[winsomeglint]

My concern with allowing beam_size and num_hypotheses to be determined by the requestor is that both of these have a significant effect on resource consumption—beam_size especially. Someone could theoretically blow the GPU out in a single pass if they set it high enough. I prefer putting them all onto a worker config and actually moving away from payload completely, or else setting a beam_size max (I'm also going to drop num_hypotheses for now since we're only ever returning the highest scorer).

[ClemDoum]

That sounds reasonable agreed