Make MediaWiki MLP jobs tunable + add reportable tuned preset (#702)

[charles-typ]

Summary:

Problem: MediaWiki tuning sweeps on Phoenix (NUMA-1) appeared to produce
"no valid result" in benchpress. The runs themselves were fine -- they
produced metrics JSON + mpstat artifacts -- but they were launched under
custom job names (mw_mlp_r1_tuned, mw_mlp_r1_c512, mw_mlp_r3_tuned) via a
local -j jobs file. benchpress report <name> returns "No job found" for
unregistered names, so those results never rolled into the DCPerf geomean.
From the reporting tool's view, the data did not exist.

Why: The registered oss_performance_mediawiki_mlp* jobs only template
scale_out (-R) and client_threads (-c). To vary server_threads (-t) or
memcache_threads (-m) -- needed for the R1/t400 single-large-HHVM variant --
users had to fork the job under a new name, orphaning the result from
report/geomean.

Fix:

• Add -t{server_threads} and -m{memcache_threads} to the registered
  oss_performance_mediawiki_mlp, _mlp_no_jit, and _mem jobs. New vars
  default to 0, which run.sh already interprets as "use computed default",
  so stock behavior is unchanged (verified: stock _mlp still expands to
  R2/t200/c256 on a 128-core host).
• Add a new registered preset oss_performance_mediawiki_mlp_tuned
  (R1/t400/c256/m64) capturing the best-performing tuning variant, so it
  reports + rolls into the geomean like any first-class job.
• run.sh: guard -m0 to fall back to the computed default, matching the
  existing -R0/-t0/-c0 guards.

Differential Revision: D110121020

[meta-codesync]

@charles-typ has exported this pull request. If you are a Meta employee, you can view the originating Diff in D110121020.