Remove outdated thread-safety docs

The Store is now `@MainActor`, so I think we can remove these warnings.

Author: stephencelis

Sources/ComposableArchitecture/Store.swift

@@ -83,55 +83,6 @@ import SwiftUI
 /// }
 /// ```
 ///
-/// ### Thread safety
-///
-/// The `Store` class is not thread-safe, and so all interactions with an instance of ``Store``
-/// (including all of its child stores) must be done on the same thread the store was created on.
-/// Further, if the store is powering a SwiftUI or UIKit view, as is customary, then all
-/// interactions must be done on the _main_ thread.
-///
-/// The reason stores are not thread-safe is due to the fact that when an action is sent to a store,
-/// a reducer is run on the current state, and this process cannot be done from multiple threads.
-/// It is possible to make this process thread-safe by introducing locks or queues, but this
-/// introduces new complications:
-///
-///   * If done simply with `DispatchQueue.main.async` you will incur a thread hop even when you are
-///     already on the main thread. This can lead to unexpected behavior in UIKit and SwiftUI, where
-///     sometimes you are required to do work synchronously, such as in animation blocks.
-///
-///   * It is possible to create a scheduler that performs its work immediately when on the main
-///     thread and otherwise uses `DispatchQueue.main.async` (_e.g._, see Combine Schedulers'
-///     [UIScheduler][uischeduler]).
-///
-/// This introduces a lot more complexity, and should probably not be adopted without having a very
-/// good reason.
-///
-/// This is why we require all actions be sent from the same thread. This requirement is in the same
-/// spirit of how `URLSession` and other Apple APIs are designed. Those APIs tend to deliver their
-/// outputs on whatever thread is most convenient for them, and then it is your responsibility to
-/// dispatch back to the main queue if that's what you need. The Composable Architecture makes you
-/// responsible for making sure to send actions on the main thread. If you are using an effect that
-/// may deliver its output on a non-main thread, you must explicitly perform `.receive(on:)` in
-/// order to force it back on the main thread.
-///
-/// This approach makes the fewest number of assumptions about how effects are created and
-/// transformed, and prevents unnecessary thread hops and re-dispatching. It also provides some
-/// testing benefits. If your effects are not responsible for their own scheduling, then in tests
-/// all of the effects would run synchronously and immediately. You would not be able to test how
-/// multiple in-flight effects interleave with each other and affect the state of your application.
-/// However, by leaving scheduling out of the ``Store`` we get to test these aspects of our effects
-/// if we so desire, or we can ignore if we prefer. We have that flexibility.
-///
-/// [uischeduler]: https://github.com/pointfreeco/combine-schedulers/blob/main/Sources/CombineSchedulers/UIScheduler.swift
-///
-/// #### Thread safety checks
-///
-/// The store performs some basic thread safety checks in order to help catch mistakes. Stores
-/// constructed via the initializer ``init(initialState:reducer:withDependencies:)`` are assumed
-/// to run only on the main thread, and so a check is executed immediately to make sure that is the
-/// case. Further, all actions sent to the store and all scopes (see ``scope(state:action:)-90255``)
-/// of the store are also checked to make sure that work is performed on the main thread.
-///
 /// ### ObservableObject conformance
 ///
 /// The store conforms to `ObservableObject` but is _not_ observable via the `@ObservedObject`