Remove Sendable from AsyncBufferedByteIterator (#220)

# Motivation
I raise on the pitch of `AsyncBufferedByteIterator` on the forums that I think the iterator must not be `Sendable`. The reasoning for this is twofold. First, an iterator is the connection of a consumer to the `AsyncSequence`; therefore, iterators should not be shared since it breaks that assumption. Secondly, the implementation of the `AsyncBufferedByteIterator` can be more straight forward since we don't have to check for unique ownership of the storage.

# Modification
Remove the `Sendable` conformances from  `AsyncBufferedByteIterator`.

Author: FranzBusch

Sources/AsyncAlgorithms/AsyncBufferedByteIterator.swift

@@ -39,7 +39,7 @@
 ///     }
 ///
 ///
-public struct AsyncBufferedByteIterator: AsyncIteratorProtocol, Sendable {
+public struct AsyncBufferedByteIterator: AsyncIteratorProtocol {
   public typealias Element = UInt8
   @usableFromInline var buffer: _AsyncBytesBuffer
 
@@ -64,10 +64,13 @@ public struct AsyncBufferedByteIterator: AsyncIteratorProtocol, Sendable {
   }
 }
 
+@available(*, unavailable)
+extension AsyncBufferedByteIterator: Sendable { }
+
 @frozen @usableFromInline
-internal struct _AsyncBytesBuffer: @unchecked Sendable {
+internal struct _AsyncBytesBuffer {
   @usableFromInline
-  final class Storage: Sendable {
+  final class Storage {
     fileprivate let buffer: UnsafeMutableRawBufferPointer
 
     init(
@@ -85,7 +88,7 @@ internal struct _AsyncBytesBuffer: @unchecked Sendable {
     }
   }
 
-  @usableFromInline internal var storage: Storage
+  @usableFromInline internal let storage: Storage
   @usableFromInline internal var nextPointer: UnsafeRawPointer
   @usableFromInline internal var endPointer: UnsafeRawPointer
 
@@ -110,24 +113,6 @@ internal struct _AsyncBytesBuffer: @unchecked Sendable {
     }
     try Task.checkCancellation()
     do {
-      // If two tasks have access to this iterator then the references on
-      // the storage will be non uniquely owned. This means that any reload
-      // must happen into its own fresh buffer. The consumption of those
-      // bytes between two tasks are inherently defined as potential
-      // duplication by the nature of sending that buffer across the two
-      // tasks - this means that the brief period in which they may be
-      // sharing non reloaded bytes is to be expected; basically in that
-      // edge case of making the iterator and sending that across to two
-      // places to iterate is asking for something bizzare and the answer
-      // should not be crash, but it definitely cannot be consistent.
-      //
-      // The unique ref check is here to prevent the potentials of a crashing
-      // scenario.
-      if !isKnownUniquelyReferenced(&storage) {
-        // The count is not mutated across invocations so the access is safe.
-        let capacity = storage.buffer.count
-        storage = Storage(capacity: capacity)
-      }
       let readSize: Int = try await readFunction(storage.buffer)
       if readSize == 0 {
         finished = true