[WorkflowTests] Support assertions which throw

[nononoah]

Summary

This PR makes allowances for throwing assertions in ActionTester.verify and RenderTester.render. These changes are meant to support tests which take advantage of XCTest's expanding API for test cases which throw.

Example of the impact of this change:

Old:

func test_saveEvents() {
    Action
        .tester(withState: state)
        .send(action: .beginSave)
        .verifyOutput { output in
            XCTAssertEqual(output.events[0], .startedSave)
        }
}

New:

func test_saveEvents() throws {
    try Action
        .tester(withState: state)
        .send(action: .beginSave)
        .verifyOutput { output in
            let first = try XCTUnwrap(output.events.first)
            XCTAssertEqual(first, .startedSave)
        }
}

Checklist

• Unit Tests
• N/A UI Tests
• N/A Snapshot Tests (iOS only)
• N/A I have made corresponding changes to the documentation

[nononoah]

These access control declaration updates were performed by SwiftFormat.

[AquaGeek]

Hmmmm. I'd rather the access control declarations live on the functions themselves (so we don't accidentally expose something that wasn't meant to be exposed). I wonder if there's a SwiftFormat flag we can change.

[dhavalshreyas]

Yeah, we haven't pinned SwiftFormat to an exact version. I guess the newer version's doing this automatically.
I'll fix.

[dhavalshreyas]

Fixed here, @nononoah can you rebase after my PR lands?

[nononoah]

Happy to do so!

[nononoah]

This tests and those that follow are demonstrative of the testing style these changes support, and serve to ensure we continue to support this testing style.

If others find them unnecessary, I'm happy to remove them.

[AquaGeek]

I think this is fine. I don't think it's strictly necessary — it's more of a "ensure the code doesn't change" test than a unit test, but this will help prevent unintended breakages.

[AquaGeek]

Thanks for taking this on, Noah!

[AquaGeek]

Hmmmm. I'd rather the access control declarations live on the functions themselves (so we don't accidentally expose something that wasn't meant to be exposed). I wonder if there's a SwiftFormat flag we can change.

[AquaGeek]

I think this is fine. I don't think it's strictly necessary — it's more of a "ensure the code doesn't change" test than a unit test, but this will help prevent unintended breakages.