While it would be nice for the `@PresentationState` property wrapper to
"just work" with TCA's upcoming observable tools, sadly that does not
seem to be the case. Adding observation directly to
`@PresentationState`, as we have done with the beta so far, can break
existing projects due to the additional observation. This primarily
manifests itself in projects that present navigation stacks, where the
`@PresentationState` observation can cause the navigation hierarchy to
recompute and trigger SwiftUI bugs.

The best we've come up with so far is introducing a brand new macro that
automatically wraps a property with `@PresentationState` _and_
instruments it with observation.

We're open to other ideas, and we do have future plans to eliminate the
need for a property wrapper or macro at all, but till then this offers a
non-breaking upgrade path!

This reverts commit f221ed0.

* Add `@Presents` macro for observable presentation

While it would be nice for the `@PresentationState` property wrapper to
"just work" with TCA's upcoming observable tools, sadly that does not
seem to be the case. Adding observation directly to
`@PresentationState`, as we have done with the beta so far, can break
existing projects due to the additional observation. This primarily
manifests itself in projects that present navigation stacks, where the
`@PresentationState` observation can cause the navigation hierarchy to
recompute and trigger SwiftUI bugs.

The best we've come up with so far is introducing a brand new macro that
automatically wraps a property with `@PresentationState` _and_
instruments it with observation.

We're open to other ideas, and we do have future plans to eliminate the
need for a property wrapper or macro at all, but till then this offers a
non-breaking upgrade path!

* wip

* Fix runtime warning when binding accesses perceptible state.

* Fix runtime warning in SwiftUI bindings.

* wip

* wip

* wip

* wip

* wip

* wip

* wip

* wip

---------

Co-authored-by: Stephen Celis <[email protected]>

…eet` (#2613)

* Fix perception warning in ForEach.

* fix

---------

Co-authored-by: Brandon Williams <[email protected]>

* Add back @ViewAction macro.

* wip

* wip

* wip

* wip

* wip

* clean up

* wip

* wip

* fix migration guide'

* ViewActionable

* wip

* rename

* wip

* wip

---------

Co-authored-by: Stephen Celis <[email protected]>

* Introduce @BindableStore.

* docs

* wip

* wip

* fixc

* wip

* wip

* wip

* wip

---------

Co-authored-by: Stephen Celis <[email protected]>

These uncached operations can be problematic, especially when working
with observation, which often depends on the stable identity of stores.

#2622)

* Skip perception checks when calling reducers.

* inline withoutPerceptionChecking() for RELEASE

Co-authored-by: Brandon Williams <[email protected]>

---------

Co-authored-by: Brandon Williams <[email protected]>

* Don't show perception warnings in action closures.

* wip

* wip

* wip

* clean up

* wip

---------

Co-authored-by: Stephen Celis <[email protected]>

* Fix some @ViewAction annoyances.

* wip

* wip

* wip

* wip

* wip

* wip

* Add new view modifiers for observing alerts/dialogs

Instead of:

```swift
.alert(store: store.scope(state: \.$alert, action: \.alert))
```

You can now do:

```swift
.alert($store.scope(state: \.alert, action: \.alert))
```

This new modifier is powered by the same store binding scope operation
that can power `sheet(item:)`, etc., and is much lighter weight than the
previous view modifier, which spun up view stores and `WithViewStore`
views.

* wip

* wip

* wip

---------

Co-authored-by: Brandon Williams <[email protected]>

* Fix uncached warning when using Store.ifLet

* wip

* wip

* wip

* wip

* wip

* wip

---------

Co-authored-by: Stephen Celis <[email protected]>

* Remove ObservationRegistrarWrapper.

* Delete Sources/ComposableArchitecture/Internal/ObservationRegistrarWrapper.swift

---------

Co-authored-by: Stephen Celis <[email protected]>