Support NUM_MACHINES as minimum floor when used with TEST_TIME

Description:
---

Currently, when both NUM_MACHINES and TEST_TIME are provided to TKG's parallel list generation, NUM_MACHINES takes absolute priority and TEST_TIME is completely ignored. This prevents using dynamic time-based parallelization with a guaranteed minimum number of machines.

Current Behavior:

NUM_MACHINES only → Uses exact number ✅
TEST_TIME only → Dynamically calculates optimal machines ✅
NUM_MACHINES + TEST_TIME → Uses NUM_MACHINES exactly, ignores TEST_TIME ❌

Some test targets (e.g., sanity.openjdk) complete in 12-45 minutes on faster platforms when NUM_MACHINES sets 3 machines, setting a TEST_TIME to 30 or 60min slows it down, while setting TEST_TIME 15min is unreasonable for slower platforms.

Proposed Solution
---

When both NUM_MACHINES and TEST_TIME are provided, use NUM_MACHINES as a minimum floor rather than an exact value:

Calculate optimal machines based on TEST_TIME and test durations
If calculated machines < NUM_MACHINES, redistribute tests across NUM_MACHINES machines
If calculated machines ≥ NUM_MACHINES, use the calculated value

Example:

make genParallelList NUM_MACHINES=2 TEST_TIME=90 TEST=sanity.openjdk

TEST_TIME calculates 1 machine (tests fit in 90 min)
NUM_MACHINES=2 ensures minimum 2 machines
Result: Tests distributed across 2 machines

Current Workaround in aqa-tests
---
The aqa-tests Jenkins pipeline implements this pattern at the Groovy level (JenkinsfileBase lines 260-283) with hardcoded minimums per target:
https://github.com/adoptium/aqa-tests/blob/master/buildenv/jenkins/JenkinsfileBase#L266

sanity.jck/extended.jck: min 10 machines (15 on Windows)
sanity.functional (Windows): min 6 machines
hotspot openjdk/system: min 3 machines

This requires:

1. Multiple calls to genParallelList
2. Target-specific hardcoded values
3. Jenkins-level logic duplication

Benefits of TKG-level Implementation
---
User flexibility: Set minimum per invocation without code changes
Cleaner architecture: Logic in TKG core, not scattered across consumers
Better performance: Single calculation vs multiple genParallelList calls
Reusability: Available to all TKG consumers, not just jenkins users using aqaTestPipeline.groovy

For eg: https://github.com/eclipse-openj9/openj9/blob/master/buildenv/jenkins/common/pipeline-functions.groovy#L442 can use it without adding workaround codes

Start by tracing TKG's genParallelList handling of NUM_MACHINES and TEST_TIME, then compare it with the workaround in aqa-tests' buildenv/jenkins/JenkinsfileBase around lines 260-283. Verify the implementation by confirming that TEST_TIME-derived machine counts never fall below NUM_MACHINES and that tests are distributed across the resulting machine count.

Written by the indexing model from the issue text.