Build the trees in parallel

[Kerollmops]

This PR plans to build the trees in parallel and store the tree nodes in files before storing them in the database using the write transactions.

However, the current implementation needs to be fixed. We are creating read transactions to be able to read from different threads in parallel, but those transactions can only read the committed changes, which means that it cannot see the non-committed user items/vectors.

After some research, I found a clean solution to the original problem. As it is valid to keep pointers to the entries' data safely (if not using fancy LMDB features like encryption), I created the ImmutableLeafs data structure that lists the leaf nodes and keeps pointers to them, all of that from the current RwTxn. We, therefore, no longer need to commit the user items transaction before being able to build the trees.

TODO

• Check and fix the tests.
• Compute the n_trees by ourselves.
• Update the README.
• Use the right TMPDIR variable.
• Document the ImmutableLeafs and specifically the safety of it (because it is).
• Rename the build_in_parallel method into the build one.

[Kerollmops]

I did some experiments to compare the speed and size of the database with Spotify/Annoy. The results are very good for arroy. We are always faster and the database is always smaller.

That's probably related to the high number of mutex and synchronisation needed to store tree nodes in the Annoy database format where Meilisearch/arroy only requires a single atomic sequential number.

On the other hand, the size of the database probably differs from the fact that we store lists of integers in RoaringBitmaps instead of in uncompressed lists as Annoy does.

When Meilisearch/arroy takes 52s to index 95832 vectors of 678 dimensions in 200 trees by using 12 threads, Spotify/Annoy takes 69s. And when we force both library to use a single thread Arroy takes 225s when Annoy takes 338s. Even if we are using LMDB and documents are stored in a B-Tree that supports atomic operations.