perf: add parallelization

[gabyx]

Proposed Changes

• Add parallelization over rayon which lets you convert an iterator to a ParallelIterator which
  is parallelized over rayon's thread pool.
  Note: rio's into_iterator is abit stupid written, dont see the intention to store a full Vec<T>

• Add a CLI flag --parallel which will use parallelization

• If the parallelization pays out has yet to be tested. The Mutex on the Writer is not particularly good I guess. -> use slogs async writter which is buffered and is Send + Sync...

Types of Changes

What types of changes does your code introduce? Put an x in the boxes that
apply

• A bug fix (non-breaking change which fixes an issue).
• A new feature (non-breaking change which adds functionality).
• A breaking change (fix or feature that would cause existing
  functionality to not work as expected).
• A non-productive update (documentation, tooling, etc. if none of the
  other choices apply).

Checklist

Put an x in the boxes that apply. You can also fill these out after creating
the PR. If you're unsure about any of them, don't hesitate to ask. We're here to
help! This is simply a reminder of what we are going to look for before merging
your code.

• I have read the
  CONTRIBUTING
  guidelines.
• I have added tests that prove my fix is effective or that my feature
  works.
• I have added the necessary documentation (if appropriate).

Further Comments

[cmdoret]

The clippy settings and code cleanup are welcome additions, but the parallelization of tripsu index degrades performance on my side (see comments).

[gabyx]

@cmdoret , @supermaxiste : the write call on Writer was wrong, only clippy mentioned this: -> write returns how many bytes have been written, which was ignored lol, I thought is a general error =), not all bytes being written is a possibility. So the correct function here is write_all. 👍

[gabyx]

@gabyx : This PR is draft, and should be revisited once parallelization is needed with longer work on the pseudonomization function

[supermaxiste]

We can revisit this idea with a different approach. We can break down tripsu's pipeline as follows:

1. Reader Thread – reads input line-by-line and sends it to a worker pool.
2. Worker Pool – multiple threads process/pseudonymize triples concurrently.
3. Writer Thread – receives processed data and writes sequentially to output.

The crate crossbeam can help implement the approach above and basically multithread on the pseudonymization process for all triples that require it.

This approach seems scalable and it also keeps copy-on-write performance gains by simply skipping the worker pool when not needed 👍