Fixed wrong result for l2Pool2d when sliding window having two valid elements

[BruceDai]

This PR is to fix the issue reported on https://issues.chromium.org/issues/383232123, the details of issue-383232123 as below.

Two tests cases fail on multiple platforms due to incorrect expected results when the output size is rounded up, requiring implicit zero padding:

l2Pool2d float32 4D tensor options.roundingType=ceil
l2Pool2d float32 4D tensor options.outputSizes ignores options.roundingType=floor
Both give following error for the [0, 2] output element:

assert_true: assert_array_approx_equals_ulp: test l2Pool2d float32 actual 90.6768569946289 should be
 close enough to expected 8222.29296875 by the acceptable 11 ULP distance, but they have 55254687 ULP
 distance expected true got false
The expected value of 8222 is not possible since the input elements are all < 100. The actual value of 90.677 has been confirmed correct via ORT CPU, multiple GPU implementations and manual calculation.

@fdwr @huningxin PTAL, thanks!

[huningxin]

LGTM!

[fdwr]

Hmm, it's kinda complicated to figure this out, given the special cases for the first and last element. Looking at what you did for other similar cases like how you implemented reduceSumSquare and reduceLogSum, would it be simpler and more compositional to implement 2D Lebesgue pooling (y = (x1^p + x2^p + ... + xn^p) ^ (1/p)) as:

export function l2Pool2d(input, options = {}) {
  const squaredInput = pow(input, new Scalar(2));
  const pooledInput = pool2d(squaredInput, sumReducer, options);
  return pow(pooledInput, new Scalar(0.5));
}

export function reduceSumSquare(input, options = {}) {
  return reduceSum(pow(input, new Scalar(2)), options);
}

export function reduceLogSum(input, options = {}) {
  return log(reduceSum(input, options));
}

[BruceDai]

Updated! Please take another look, thanks!

[fdwr]

Yeah, much clearer (at least to me, and hopefully later generations of readers after us too 😉).

[fdwr]

Reapproving after data merge.