Accessing non-shared locals insides shared-barrier

At the meeting today we discussed how it would be useful for shared-barrier to work like let and introduce new non-shared locals that could be accessed only inside the barrier block. However, let had a bunch of usability issues that caused us to discard it in favor of tracking the initialization state of non-nullable locals.

I realized that we could use the same strategy for non-shared locals inside shared-barrier blocks. Non-shared locals could be declared alongside other locals in shared-suspendable functions, but would not be accessible except inside shared-barrier blocks. They would start out as uninitialized at the beginning of each shared-barrier and would have to be explicitly initialized (potentially with null values) before they could be accessed. Alternatively, the beginning of the shared-barrier could implicitly set defaultable non-shared locals to their default values.

This seems to neatly solve the problem of accessing non-shared locals inside shared-barriers using only the existing mechanism of initialization tracking. It also eliminates one of the differences between shared-suspendable and shared-fixed functions by letting them declare the same kinds of locals, which seems nice.

Start by reviewing the existing shared-barrier semantics and the initialization-tracking mechanism referenced in the issue. Compare the proposed explicit-initialization and implicit-default alternatives, then determine which behavior the proposal should specify and how it would apply to shared-suspendable and shared-fixed functions.