Implement Multi-threading in FairGBM logic

[AndreFCruz]

Summary

Several CPU-bound FairGBM functions are currently single threaded.

TODO:

• Test if everything works correctly when using the following directive on (most) loops over the data: #pragma omp parallel for schedule(static)
  • The loop at ConstrainedObjectiveFunction::GetConstraintGradientsWRTModelOutput should be the focus, as it is where most CPU time is spent;
  • AFAIK the loop seems to be parallelizable: no variables seem to be changed in the same location (arrays are changed but always at the position of the given row index, therefore no race conditions should occur);
  • If not, adapt the loop such that each thread does not alter variables in common (or use locks when it's impossible to separate the logic);

[AndreFCruz]

NOTE: I added comments linking to this issue on the code sections I detected that could use omp multi-threading.
(essentially, it's every time we do a loop over the data; do a CTRL+F for i < num_data_)

[AndreFCruz]

UPDATE This issue corresponds to only a few added lines of code on the PR #18; This has already been done and is awaiting other refactors to be merged to master (other refactors will also be done on that PR).