[refactor]: improve diagnostics for escaped context instances

[jamieQ]

Issue

the {Render|Apply}Context types should not escape from their respective methods, as this can allow library internals to 'leak out' and cause various issues¹. primarily this can result in lifetime discrepancies or surprising relationships in the object graph. historically we've enforced this invariant 'lazily' by setting a bit on the instances and checking that they are still 'valid' during access through their public API. however, it recently occurred to me that we could probably be a bit more proactive about this, and perform a unique reference check immediately after returning from the client callouts.

Description

• adds logic to detect escaping context instances (debug mode only)
• adds the 'IssueReporting' dependency to Workflow so we can better test the logic in our unit tests
• minor incidental refactoring of the Package file
• updates unit tests appropriately

Footnotes

1. this is really more of an issue for RenderContext, as it doesn't yet zero-out its internal storage when invalidated. since ApplyContext is newer, we didn't make that mistake twice. ↩

[jamieQ]

standardized some of these so now all the 'package-level' dependencies are just strings, and the external ones are .product()

[amorde]

Very cool! Only question is if there's any concerns having the Workflow target now depend on the IssueReporting framework from the xctest overlay. I suppose it should be fine given we only use it in #if DEBUG, but perhaps there's some potential dependency conflicts for downstream consumers using SPM if they use a different version or something like that.

[jamieQ]

Only question is if there's any concerns having the Workflow target now depend on the IssueReporting framework from the xctest overlay. I suppose it should be fine given we only use it in #if DEBUG, but perhaps there's some potential dependency conflicts for downstream consumers using SPM if they use a different version or something like that.

yeah, i guess i'm unsure exactly what the theoretical risk is here... we have had the dependency in the package for a while, but i guess not as part of the Workflow target, so maybe that could cause problems? i think we're as permissive with the version as possible though, so maybe it's okay.

i guess i should probably also look into if the library gets built & linked in non-debug builds even if it's only referenced behind conditional compilation directives...

---

edit: i think since we've had the implicit dependency already we're okay and won't cause new issues for people due to dependency resolution (i set the dependency to what seemed like the actual minimum version we require 1.2.2). also seems there's not really a way to do non-debug build & link only, but also i think this is probably okay since it's effectively only used in debug and nothing is publicly re-exported.

[jamieQ]

converted this to XCTest b/c when testing against the oldest version of the IssueReporting dependency we support (1.2.2), for some reason the test seemed to behave differently and didn't appear to actually 'escape' the context. i assume that means there's a bug somewhere, but did not investigate.