IntroToRx recommends wrong Window overload

The [Window section of the Partitioning page](https://introtorx.com/chapters/partitioning#window) has this example:

```cs
public static IObservable> MyWindow(
this IObservable source,
int count)
{
IObservable shared = source.Publish().RefCount();
IObservable windowEdge = shared
.Select((i, idx) => idx % count)
.Where(mod => mod == 0)
.Publish()
.RefCount();
return shared.Window(windowEdge, _ => windowEdge);
}
```

That final expression is problematic:

```cs
shared.Window(windowEdge, _ => windowEdge)
```

This effectively tries to use the same sequence for both openings and closings.

People might reasonably [expect this to produce contiguous windows](https://github.com/dotnet/reactive/issues/2091), in which there are neither gaps nor overlaps. It's reasonable to think that if the same source is specifying both the starts and ends of each window, that each new window would start exactly where the previous one ends, with the effect that every item would go into exactly one window.

This is not in fact the case, because that openings/closings overload of `Window` ends up making multiple subscriptions to the same source: once in its role as the openings observable, and then once per window for the closings.

In general in Rx, multiple subscriptions to the same source do not have to produce the same events. The situation where this does happen is a special case that we describe as a 'hot source'. This is an informal term, and not something Rx actually recognizes—we talk about 'hot sources' to describe a form of behaviour, but `System.Reactive` has no way of detecting when something is acting as a hot source.

(In principle, it could recognize the use of things like `Publish`, `Multicast`, or `Subject` to detect when there logically really is a single event flowing through multiple paths. But this would require the addition of tracking of a kind Rx has never previously performed. And even if we did this, it would be too easy for the application to add a layer that made it impossible for Rx to detect this, leading to inconsistent behaviour depending on whether non-`System.Reactive` implementations are added to the mix. Currently `System.Reactive` optimizes certain cases where it detects our own operators are in use adjacently, but we aim never to change behaviour just because you've put something else in the mix.)

The IntroToRx example should be changed here. Since the example (which was brought over from the 1st edition) was apparently selected to motivate the the use of this particular form of `Window`, we might need to rewrite this bit entirely.