Refactor limits tests to only do operation/validation tests with valid limits

[greggman]

The limits tests under webgpu:api,validation,capability_checks,limits,* generally pass in kMaximumLimitBaseParams or kMinimumLimitBaseParams as test case parameter. These parameters test the limit itself as "atDefault", "underDefault", "betweenDefaultAndMaximum", "atMaximum", "overMaximum"

The tests should be split.

• 1 test that tests the limit itself at: "atDefault", "underDefault", "betweenDefaultAndMaximum", "atMaximum", "overMaximum"

  • underDefault should get the default
  • atDefault should get the default
  • betweenDefaultAndMaximum should get what's requested, not more, not less
  • atMaximum should get the maximum
  • overMaximum should fail device creation

  these cases are automatically tested by LimitTest. But we should separate out that case
  into its own test. Example

  g.test(`${limit}`)
    .desc(`Test ${limit} at various values`)
    .params('limitTest', kMaximumLimitValueTests)
    .fn(async t => {
      const { limitTest } = t.params;
      const { defaultLimit, adapterLimit: maximumLimit } = t;
      await t.testDeviceWithRequestedMaximumLimits(
        limitTest,
        'atLimit',
        async () => {}
      );
    );

  or something along those lines. A bigger refactor could simplify this test.

• Other tests that test that the limit is correctly applied (validation) and supported (operation).

  These other tests, there's no reason to test overMaximum in these cases as that should always fail device creation which would be tested by the first test above. underDefault also irrelevant as it would be the same as atDefault, so remove those from kMaximumLimitBaseParams and kMinimumLimitValueTests

[kainino0x]

For the latter, we can also dynamically skip betweenDefaultAndMaximum and/or atMaximum if it results in the same limit value as atDefault.

(i.e. on devices where the maximum is the same as the default)