`<numeric>`: `transform_inclusive_scan` passes output values to the binary (reduce) operation

[akrivx]

Describe the bug

The overload of transform_inclusive_scan that takes execution policy and initial value arguments passes the result of dereferencing the output iterator to the binary reduce operation.

Doing so requires that the output value type can be converted to the types expected by the binary operation.

Command-line test case

See this example here: https://godbolt.org/z/4fscYPcTW It's working fine with the latest gcc.

Expected behavior

transform_inclusive_scan does not pass the result of dereferencing the output iterator to the binary operation.

STL version

```
Microsoft Visual Studio Community 2022 (64-bit)
Version 17.6.2
```

[achabense]

&& transform_exclusive_scan(execution::par,...) has the same problem.

It seems the usage of _Apply_inclusive_predecessor is wrong here. https://github.com/microsoft/STL/blob/15aea9852b557f70821651600e51d9a2b3b1a95e/stl/inc/execution#L4841-L4847

[frederick-vs-ja]

It seems that we should pass _Transform_op to _Apply_inclusive_predecessor (with its signature changed) and use _Transform_op in it.

We should also pass the beginning "input" forward iterator. Perhaps we should avoid moving.

Edit: The standard doesn't seem to require parts of output range (whose element type is the value type of ForwardIterator2) to be usable as mediate results (whose element type should be T). Perhaps we need to create a new T sequence when it's impossible to reuse the output range.