[docs] add a work-around for multithreading with Gurobi

[odow]

It's pretty simple in the end, but it took me a long time to think of this! You're limited by nthreads <= min(number of nodes, number of licenses) but that seems fine.

Depending on how you partition the nodes, there might also be a lot of lock contention. It isn't obvious to me whether 1:n/2, n/2+1:n or 1:2:n, 2:2:n is better. It kind of depends on the model. But in the worst case, they cannot be worse than single threaded.

The alternative was much more complicated. We needed to create an explicit environment for each thread, and move the subproblems between environments depending on which thread was being run. That should have the same thread contention as the current algorithm, except that there would be overhead moving the models around and it isn't obvious how to do that through SDDP/JuMP/MOI/Gurobi.jl.

This approach is much simpler, and it doesn't even need any changes inside SDDP.jl.

x-ref #859 (comment)

and my discussion with Simran

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.35%. Comparing base (1b16654) to head (677e00f).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #890      +/-   ##
==========================================
+ Coverage   96.32%   96.35%   +0.02%     
==========================================
  Files          28       28              
  Lines        4032     4032              
==========================================
+ Hits         3884     3885       +1     
+ Misses        148      147       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.