Parallelize library builder discovery phase

[mattgodbolt]

Summary

This PR adds parallelization to the library builder's discovery phase, which is currently the slowest part when checking thousands of library configurations.

Changes

• Split discovery phase from building phase to enable parallelization
• Add ThreadPoolExecutor with configurable worker count
• Use thread-local storage for HTTP sessions (one per worker)
• Add --parallel-discovery CLI flag (default: 4 workers)
• Apply same pattern to Fortran and Rust builders
• Proper constructor parameters instead of attribute injection

Performance Impact

• Discovery phase should see ~3-6x speedup with 4-8 workers
• Overall runtime improvement of ~2-3x for library builds
• Better CPU utilization on expensive GitHub Actions runners

Testing

To test with different worker counts:

# Sequential (old behavior)
ce build --parallel-discovery 1 libraries/c++/fmt/trunk

# Default parallel (4 workers)
ce build libraries/c++/fmt/trunk

# More parallelism
ce build --parallel-discovery 8 libraries/c++/fmt/trunk

Notes

• Conservative default of 4 workers to avoid overwhelming the conan server
• Each worker maintains its own HTTP session for connection pooling
• Thread-safe caching with locks for shared dictionaries
• No changes to the actual build execution (remains sequential for safety)

Fixes the issue where library discovery takes extremely long on powerful machines that aren't utilizing their CPUs effectively.

[mattgodbolt]

drafting til I land a common code extraction