chore: Bump Perception to 2.0.6 (#377)

## Checklist

**Bump perception to 2.0.6**
**`tuist install --path Samples` to update Sample resolved
dependencies**

The Perception version specified in Package.swift is now
`1.5.0"..<"3.0.0`. This allows easier upgrade and downgrades by
consumers.

I've opened this in favor of
#376 because Perception has
been [updated](pointfreeco/swift-perception#156)
following Apple's reversion of
swiftlang/swift#83436 and it avoids test updates
on our end for now.

I didn't run the `tuist install` with the `--update` flag this time
either. There doesn't seem to be a way to scope the updates to only
Perception and it's sub-dependencies and I didn't want all the other
clutter associated with this change.

- [x] Unit Tests
- [x] UI Tests
- [x] Snapshot Tests (iOS only)
- [x] I have made corresponding changes to the documentation
- [x] Resolve new Perception warning in ios-register:
squareup/ios-register#131811
- [x] Resolve new instances of Perception warnings in Market:
squareup/market#11042

---------

Co-authored-by: Andrew Watt <[email protected]>

[feat]: add runtime option to skip render if state is inferred to be …

…unchanged (#364)

adds support to conditionally opt in a WorkflowHost runtime to use a
render-skipping optimization that checks if we can reasonably infer that
no workflow node state was changed during a series of action
applications. if the inference indicates no state has changed, the
render pass will be skipped. the changes made to support this include:

- adding a new `ActionApplicationResult` type to model the result of
applying an action to a node. this type carries some invalidation state
information with it to propagate up the tree.
- adding new conditional logic into the `applyAction()` method (renamed
from `openAndApply()`) to conditionally try to infer if state has
changed under the following conditions:
- if the `State` instance can be dynamically inferred to be `Equatable`,
then the before & after values will be compared to determine if the
update should be treated as invalidating state or not
- if the type of `State` is equivalent to `Void`, then it will be
treated as never having changed
- if the sequence of action applications makes it to the root node and
the final `ActionApplicationResult` indicates that no state was changed,
the root node will skip the subsequent render pass. note: if an output
event is produced, that will still be delivered and is independent of
this logic.

this change has the potential to alter observable behavior, and so is
opt-in behind a conditional runtime configuration option.

primary changes:
- `WorkflowNode.applyAction()`
- `WorkflowHost.handle()`

docs: readme gardening (#359)

Adds a link to the API docs and removes the blurb about being unstable.
It's stable.

AsyncSequenceWorker’s should not throw errors (#355)

Added catch for errors in AsyncSequenceWorker.


## Checklist

- [x] Unit Tests
- [ ] UI Tests
- [ ] Snapshot Tests (iOS only)
- [ ] I have made corresponding changes to the documentation

[fix]: bump catalyst to fix build (#352)

- bumped mac catalyst min version to 16 to fix downstream build issues
- going to treat this as a 'hotfix' followup to the 4.0.0 tag

[BREAKING CHANGE]: update WorkflowAction API to expose access to Work…

…flow instance values (#349)

this BREAKING change updates the WorkflowAction API to pass through a
new parameter in the `apply()` method that allows reading values off the
corresponding node's current Workflow instance. the new method signature
is:

```swift
func apply(toState state: inout State, context: ApplyContext<WorkflowType>) -> Output?
```

which mirrors the `render()` API, but uses a new `ApplyContext`
parameter to expose access to the runtime-managed data. the public API
for `ApplyContext` exposes a read-only subscript for accessing Workflow
values via keypath:

```swift
public struct ApplyContext<WorkflowType: Workflow> {
    public subscript<Value>(
        workflowValue keyPath: KeyPath<WorkflowType, Value>
    ) -> Value 
}
```
---

for reviewing purposes, i'd suggest using the 'commit filter' function
to exclude the commit labeled 'AUTOMATED' as that one is essentially
just noise where a bunch of new parameters were added.

also, there's definitely some more documentation to be written here, but
i've currently punted on that somewhat. do feel free to point out places
you'd like to see anything specific though.

Adds a convenience for mapping Never outputs to other types (#340)

Adds a way to map a workflow's `Never` output type to a different type
without generating compiler warnings. Fixes
#339

I like this solution because the natural inclination is to simply delete
the block containing unreachable code and that just works:

```diff
-            .mapOutput { switch $0 {} }
+            .mapOutput()
```

I'm happy to add a test using this but the true validation is to
successfully build without warnings.

Adding details to the parent dependencies section of the WorkflowSwif…

…tUI Adoption Guide (#337)

Rename `expect(worker:producingOutput:)` to be more clear about what …

…it is asserting (#323)

When I first saw tests that used this function, I thought it was
asserting that the `worker` passed in, matches the `workflow.worker`
(which it does do), and that it was asserting that `producingOutput ==
workflow.worker.output` (which it does NOT do). Instead, neither of the
workers are ever run. The `producingOutput` is used as mock output. So
renaming these to make it more clear what is going on.


## Checklist

- [x] Unit Tests
- [x] UI Tests
- [x] Snapshot Tests (iOS only)
- [x] I have made corresponding changes to the documentation

Resolve Bazel dylib issue due to aggressive code stripping (#321)

The dylib being generated internally is code stripping private vars
incorrectly. This should resolve it.

## Checklist

N/A / validated by internal CI

- [X] Unit Tests
- [X] UI Tests
- [X] Snapshot Tests (iOS only)
- [X] I have made corresponding changes to the documentation