Add moz-webgpu-cts process-reports subcmd. with multiple --presets

[ErichDonGubler]

Resolves #13, #9.

Depends on:

• Assorted fixups and refactors 😅 #32
• feat(cli)!: normalize exps. in meta. to be: by platform, by build profile #33
• Normalize outcome order for tests and subtests #39
• Refactor whippit to be a set of traits instead of structs #40
• Refactor expectations s'more, yo #42

[ErichDonGubler]

I was struggling to get traction on resolving conflicts between expected outcomes in metadata and reported outcomes. I realized I was missing an answer to the question, “How do I structure new expectations' conditional values once reports have been analyzed?” An example answer: one could organize by platform:

[test]
  [subtest]
    expected:
      if os == "win": FAIL
      if os == "linux": TIMEOUT

…or one could organize by build profile:

[test]
  [subtest]
    expected:
      if debug: FAIL
      if not debug: TIMEOUT

…or even potentially mix them, which seems reasonable, but only muddies up the solution space for “what do we emit”:

[test]
  [subtest]
    expected:
      if os == "win": NOTRUN
      if debug: FAIL

In addition to the variables explored above, WPT upstream lets users define what I'll call “branching points” in expectation structure for any run info variable. WPT upstream's update-expectations script actually has a full-blown configuration schema for defining the these branching points. These branching points can still “collapse” into a single outcome if all variations of a branching point are the same. This is neat, and solves the question we ask above. However, this leaves another problem: to implement this, we'd have to make some gnarly, complicated, dynamic code.¹

I determined to answer the question I've posed instead by (1) baking a branch point configuration into code for now, and (2) granting moz-webgpu-cts a limited knowledge of all platforms we intend to run on for now. expected properties will be divided first by supported platform, then by build profile, eliding conditionals if all variants are the same. In practice, this may mean we (1) lose granularity with things like Firefox release (e.g., nightly vs. stable) and (2) we may duplicate the same expected outcomes between different platforms on the same build profile. I think these are pretty acceptable trade-offs for getting something tractable now. We can update this model later, if this MVP needs tweaking down the road.

Footnotes

1. I wouldn't be surprised if the dynamism hurts its ceiling for performance, too. ↩

[ErichDonGubler]

Removed TestExecutionResult::duration with dd3cad3 for now; broke out #53 for later work.