Resolve capture_output deadlock in multiprocessing environments

[jsiirola]

Fixes # .

Summary/Motivation:

#3908 pointed out that we could inadvertently trigger a deadlock in multiprocessing environments. This PR attempts to resolve that by switching from a threading.Lock to a multiprocessing.Lock if multiprocessing is being used in the python process.

I am not closing the issue as the original reporters have not confirmed if it actually resolves their use case.

As part of this, I needed to overhaul the import time test / reporting logic so that we can more accurately test import timing for multiprocessing environments.

Changes proposed in this PR:

• Switch to a multiprocessing.Lock when multiprocessing is imported
• Make sure that multiprocessing is not imported by pyomo.environ
• Overhaul (and generalize) the import time reporting logic

Legal Acknowledgement

By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution:

1. I agree my contributions are submitted under the BSD license.
2. I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.10%. Comparing base (92951cb) to head (4c64b30).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3957   +/-   ##
=======================================
  Coverage   90.10%   90.10%           
=======================================
  Files         909      909           
  Lines      108525   108541   +16     
=======================================
+ Hits        97787    97804   +17     
+ Misses      10738    10737    -1     

Flag	Coverage Δ
builders	29.08% <59.37%> (+<0.01%)	⬆️
default	86.10% <100.00%> (?)
expensive	35.11% <59.37%> (?)
linux	87.62% <100.00%> (-1.99%)	⬇️
linux_other	87.62% <100.00%> (+<0.01%)	⬆️
oldsolvers	28.04% <59.37%> (+<0.01%)	⬆️
osx	83.06% <100.00%> (+<0.01%)	⬆️
win	85.37% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ 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.

[mrmundt]

Residual?

[jsiirola]

No: that is part of the comment text

[mrmundt]

i am fine with this as-is. "Future Us" concern: test_environ could be potentially overly sensitive to internal Python changes, particularly across versions.