Fix thread-safety in C API's PredictSingleRow (#3771)
Fix thread-safety in C API's PredictSingleRow (#3771)

By using a unique lock instead of the shared lock the timings are very similar,
but predictions are correct.

Even so, by designing a small C++ benchmark with a very simple LGBM model,more threads on a simple model are slower than
the single-thread case. This is probably due to very small work units,
the lock contention overhead increases.

We should in the future benchmark with more complex models to see if supporting
threading on these calls is worth it in performance gains.

If not, then we could choose to not to provide thread-safety and remove
the locks altogether for maximal throughput.

See https://github.com/microsoft/LightGBM/issues/3751 for timings.

See gist for benchmark code:

  https://gist.github.com/AlbertoEAF/5972db15a27c294bab65b97e1bc4c315
microsoft/LightGBM,microsoft/LightGBM,microsoft/LightGBM,microsoft/LightGBM,henry0312/LightGBM,henry0312/LightGBM,henry0312/LightGBM,microsoft/LightGBM,henry0312/LightGBM,henry0312/LightGBM