Consider moving Streams to use simpler, single-threaded Cancellation token

[dsyme]

As far as I can tell stream iteration is inherently single threaded in the sense that, like Seq, the Iterable and Iterator objects are accessed linearly.

In this setting, the use of CancellationTokenSource has costs because accesses are multi-threaded ready and are ultimately synchronized via a Volatile field. So I experimented with changing to use simpler, single-threaded Stream cancellation tokens. The branch and diff is here: dsyme/Streams@hide-reprs...dsyme:no-cts-for-streams (this builds on #31 and #30). In some cases the code seems to be simpler in any case (since we effectively switch between Boolean flags and cancellation tokens in any case) unless there's something I've missed.

Note that no disposal is needed on these since they don't have wait handles

Raw iteration performance seems to be improved by around 5-10%:based on the runStream() sample in Streams.fs

If you think this is a good idea I can submit a PR.

AFTER:

Real: 00:00:02.286, CPU: 00:00:02.234, GC gen0: 0, gen1: 0, gen2: 0
Real: 00:00:02.299, CPU: 00:00:02.296, GC gen0: 0, gen1: 0, gen2: 0
Real: 00:00:02.325, CPU: 00:00:02.296, GC gen0: 0, gen1: 0, gen2: 0
Real: 00:00:02.257, CPU: 00:00:02.234, GC gen0: 0, gen1: 0, gen2: 0
Real: 00:00:02.225, CPU: 00:00:02.234, GC gen0: 0, gen1: 0, gen2: 0
Real: 00:00:02.252, CPU: 00:00:02.250, GC gen0: 0, gen1: 0, gen2: 0
Real: 00:00:02.350, CPU: 00:00:02.328, GC gen0: 0, gen1: 0, gen2: 0
Real: 00:00:02.207, CPU: 00:00:02.218, GC gen0: 0, gen1: 0, gen2: 0
Real: 00:00:02.218, CPU: 00:00:02.218, GC gen0: 0, gen1: 0, gen2: 0
Real: 00:00:02.208, CPU: 00:00:02.187, GC gen0: 1, gen1: 0, gen2: 0

before:

  //   Real: 00:00:02.384, CPU: 00:00:02.375, GC gen0: 0, gen1: 0, gen2: 0
  //   Real: 00:00:02.490, CPU: 00:00:02.484, GC gen0: 0, gen1: 0, gen2: 0
  //   Real: 00:00:02.362, CPU: 00:00:02.343, GC gen0: 0, gen1: 0, gen2: 0

[palladin]

Actually I was aware of the multithreaded nature of CancellationTokenSource (I'm using it in ParStream) but I thought that is was lightweight enough and that I pay the allocation cost only for early termination combinators like (take, find etc)