Our gradle build spawns up to `NUM_COMPILE_THREADS` compilation tasks in parallel when building native libraries. By default, `NUM_COMPILE_THREADS` is set to the value returned by `Runtime.getRuntime().availableProcessors()`. That value can be overridden on the command line by setting the `NUM_COMPILE_THREADS` gradle property. We need is a way to clamp `NUM_COMPILE_THREADS` at some maximum value without the caller having to compute it.

The change in `build.gradle` is simple:

* Define a new `MAX_COMPILE_THREADS` gradle property, which will default to 0 (meaning unlimited) for compatibility with current behavior.

* Set the default value of `NUM_COMPILE_THREADS` as follows:

```
    numProc = Runtime.runtime.availableProcessors()
    NUM_COMPILE_THREADS = MAX_COMPILE_THREADS > 0 ? Math.min(MAX_COMPILE_THREADS, numProc) : numProc
```

This will allow a test scripts that runs on a number of different platforms to clamp to a maximum value without having to use jshell or similar to implement `Math.min(MAX_COMPILE_THREADS, Runtime.getRuntime().availableProcessors())` in the script.

We have a practical need for this in our headful test systems, several of which report a higher number of processors than they can effectively support. Without clamping, the build will either run slower (due to too much swapping) or fail altogether when building WebKit.