build: auto-set GitHub runner make job count

[iamamyth]

Dynamically determine an appropriate number of make jobs for the GitHub runner container, based upon the number of available CPU cores and RAM, using the rule that each job requires a dedicated core and 2.25GiB of RAM.

[selsta]

Seems this does not compile with Debian and Ubuntu CI jobs

[iamamyth]

This PR follows from the discussion in #9510. Based on testing with GitHub macOS runners, I determined the suitable memory requirement to be 2.25GiB per runner, rather than the 2.75GiB hypothesized in the thread: With three jobs (current config) on a 3 CPU + 7GiB machine, a full build takes roughly 8m 24s, versus 11m 10s with two jobs. Due to noisy neighbors, there's considerable performance variance (observed 40s difference between two identical runs), but the results suggest 2.25GiB suffices.

Should the need arise, this PR allows custom memory requirements to be set per OS.

Build output confirms this PR results in job counts identical to the current fixed configuration (by design, the dynamically determined count appears in the build output because it's sourced from an environment variable).

[iamamyth]

@selsta Build should now work. A typo snuck in when preparing a rebased version of this branch and I couldn't fix it due to GitHub instability (also the reason my prior comment follows the PR by an hour).

[plowsof]

Looks good so far although my basic arithmetic skills are horrendous (thank you for the 9/4 comment which i seen later, i have just about grasped that 2.25 = 9 quarters)

"But where's the math.floor?" i asked myself. TIL Bash does floor rounding by division automatically 1

The only suggestion i have would be returning the ram in bytes at the source rather than dealing with 3 different units.

powershell can return value in bytes directly "TotalPhysicalMemory"2 and vmstat has --unit B.

untested: powershell -Command "(Get-CimInstance Win32_ComputerSystem).TotalPhysicalMemory"

[iamamyth]

If it were trivial to achieve, I would have initially used a common unit (probably KiB, because that's what /proc/meminfo reports, as bytes are unreasonably small). I'd rather not have anything to do with powershell, as that introduces a second major set of OS tools. I could change vmstat to use KiB, but I'm not sure exactly what that would accomplish: It's fairly obvious the command reports MiB, and the unit conversions between KiB, MiB, and GiB, aren't particularly complex (aside from the appearance of k, M, etc, in the commands, the denominators also pretty clearly indicate the scales, and relations between them).