Use Batch API to avoid timeouts when updating large number of references

Thank you for your work here. Could this please be rerolled against 2.x as MR with tests?

Created an MR against 2.x with the patch from #18 + minor changes. The difference with #20 is mainly a separate batch method in the manager and config for the batch size. The tests still use the non-batch method.

However, since this is only an api module, I would consider all this code to be in the wrong place. The term merge module is where the UI is and the batch_set should be implemented over there. This does require a bit of splitting up of `migrateReference` in the service.
Any functional javascripts for that should also be added in term merge.

The MR works fine but to get the list of entities, the entities are being loaded which may lead to memory limit reach problems IMO. I suggest to, in the batch migrate, instead of loading the entities at the beginning, get the ID list and then in the batch callback load the entity. What do you think?

I've updated the MR by loading only the entity IDs in the batch setup, and loading the entities in each batch iteration, may somebody check?

In agreement with the statement in #27, batch_set needs to be done outside of the batchMigrateReference function.

I've created a patch that can be applied on top of MR 7 (apologies, not familiar with MR process). It changes batchMigrateReference to getMigrateReferenceBatchOperations which returns an array of operations to use in a batch_set call outside of this module.

Andriy Khomych → made their first commit to this issue’s fork.

Sorry to jump on it :) I think it makes sense to include #32 as batch (or queue) should be set outside.

Attached patch from MR.