Scope locals

[Paul Sandoz]

Hi Andrew,

Recent commits promoted me to play around with the code. Some observations, comments and suggestions below.

- I like the conciseness of the API, and that of the implementation. It could potentially stand on its own separate from virtual threads as an independent JEP.

- There seem to be two forms of inheritance, intra-thread inheritance by nesting scoped execution within the same thread, and inter-thread inheritance by implicit hand-off from a parent thread to a child thread. In the former case both kinds of scope local are inherited, whereas for the latter only those constructed by “inheritableForType” are inherited.

- In addition to inheritance, there is the notion of explicit handoff with snapshotting of locals created by “inheritableForType”.

- It might be useful for inter-thread inheritance to build a Carrier without any scope locals (i.e. no `where` calls), enabling inheriting those from the parent thread without having to create a dummy scope. I think it may be possible by doing ScopeLocal.runWithSnapshot(() -> { … }, ScopeLocal.snapshot()), but that is not very obvious.

- I might be missing something subtle here, but I wonder if it may be possible to unify Carrier and Snapshot. AFAICT it is possible to pass an instance of Carrier around, and hand off much like an instance of Snapshot can be. What if ScopeLocal.snapshot() returns an instance of Carrier, that only refers to locals for inter-thread inheritance in the context of the current thread? Then there is no need to special case scoped execution with a snapshot. That would be pleasing collapse of the API to a lower energy state.

- Naming-wise Carrier could be named ScopeMap, thereby capturing what is described on its class docs. This might help with the prior observation, if applicable.

- Records could be very useful when declaring multiple values bound together in scope, rather than multiple scoped locals. They would become more useful if there was a `wither`-like language construct for creating a new record, replacing some components and copying the other components from a given record. Still, even without such a language construct it may be worth mentioning records in an API note as a possible usage pattern.

Hth,
Paul.