Expose IndexWriter::wait_merging_threads()

[GodTamIt]

This can be useful if certain clients wants to wait for the merging to finish before issuing further commits.

[cjrh]

Looks good. Can you add a test (in python) that calls the new wait method? Like a python version of one of these in the tantivy tests, e.g.

    #[test]
    fn test_with_merges() -> crate::Result<()> {
        let mut schema_builder = schema::Schema::builder();
        let text_field = schema_builder.add_text_field("text", TEXT);
        let index = Index::create_in_ram(schema_builder.build());
        let reader = index
            .reader_builder()
            .reload_policy(ReloadPolicy::Manual)
            .try_into()?;
        let num_docs_containing = |s: &str| {
            let term_a = Term::from_field_text(text_field, s);
            reader.searcher().doc_freq(&term_a).unwrap()
        };
        // writing the segment
        let mut index_writer = index.writer(12_000_000).unwrap();
        // create 8 segments with 100 tiny docs
        for _doc in 0..100 {
            index_writer.add_document(doc!(text_field=>"a"))?;
        }
        index_writer.commit()?;
        for _doc in 0..100 {
            index_writer.add_document(doc!(text_field=>"a"))?;
        }
        //  this should create 8 segments and trigger a merge.
        index_writer.commit()?;
        index_writer.wait_merging_threads()?;
        reader.reload()?;
        assert_eq!(num_docs_containing("a"), 200);
        assert!(index.searchable_segments()?.len() < 8);
        Ok(())
    }

Or if you have a simpler idea for a test that's fine too.

[adamreichold]

Really not sure about which way to go with the exception, otherwise looks fine to me.

[GodTamIt]

I went with a RuntimeError there. Nothing fits perfectly here, but based on the documentation, RuntimeError seems to be the appropriate catch-all.

This change can be squash-merged