Performance optimizations in Analysis Request creation

[xispa]

This Pull Request contains very small changes, but it makes ~185 analyses from a Profile or Template get populated in less than 3s in AR Add form, even with the creation of 4 Analysis Request at once. With this PR, a delay because of BatchUID reindexing on analyses has been fixed too. As a result, the process of creation of an Analysis Request is significantly faster than before:

• Creation of 1 Analysis Request with 184 analyses: before ~3m, after ~1m5s.
• Creation of 1 Analysis Request with 94 analyses: before ~2m, after ~30s.

For these numbers, a laptop has been used, with a standalone instance, started in fg mode and with other applications (email, firefox, openoffice and PyCharm) running, so the numbers should be better in a dedicated server with an instance with zeo mode.

Breakdown of processes that take more than 1s during the creation of an AR with 94 analyses:
a) Submission of form: ~15s
b) Transition of AR to sampled : ~8s
c) Transition of AR to sample_due: ~8s

The most time-consuming task is the creation of the AR by using the ar.processForm(REQUEST=request, values=values) https://github.com/naralabs/bika.lims/blob/d827845190fd78ba55fe2359dee73152ae61cfb7/bika/lims/utils/analysisrequest.py#L75, but don't think there is too much room for improvement here unless we remove fields from the Schema and ensure there is no Created/ModifiedEventHandlers that makes the system to be slow. In any case, worth to review in detail.

Regarding transitions, there is still window for improvement, specially because the Analysis Request object (as well as Sample, Partitions and Analyses) needs to be transitioned several times (sample_received -> sampled -> sample_received) before reaching the desired state. There is some overhead because of transitions cascading and promotion, and there is work going on to address these shortcomings already.