Add shared native memory proposal

[mraleph]

This extracts relevant parts of the bigger proposal into a separate proposal.

The following things have changed:

• We now include formal memory model: our formalization pretty much follows JavaScripts with some minor tweaks.
• All atomic operations are consolidates in a single AtomicInt class - which can be constructed as a view on Pointers or TypedData objects. This is a departure from the previous "zoo of extension methods" design. We should discuss if it is actually better.
• I introduced ScopedThreadLocal class which should address some known problematic usages of static state in core libraries.
• There are few design points (marked with TODO in the text) which I don't have concrete answers to. We should discuss these.

@lrhn @mkustermann @aam can you take a look?

@aam could you give me the current state of core-library APIs (which already work from IG bound code, which you are fixing and which we will not support). I want to align on what we think is MVP here and include this into the proposal.

[mraleph]

cc @leafpetersen

[aam]

Nice, but outside of isolate-group-bound callbacks, in the context of standard isolates, does ScopedThreadLocal instance behave like a static field? Isolates in the end can migrate from one thread to another.

[mraleph]

Note that isolates can't move between threads in synchronous calls and this API is fully synchronous.

[aam]

Will there be something that would prevent this infrastructure from being used in asynchronous context?

 static Future<String> iterableToShortString(...) {
  return toStringVisiting.use((toStringVisitingValue) async {
    await Future.delayed(Duration(seconds: 10));
    ...

[mraleph]

You can use it. But it is not going to do anything useful because the value of the scoped thread local will reset once the synchronous execution completes.

[aam]

So toStringVisiting can become unbound after await Future.delayed(Duration(seconds: 10)) (in unlikely event) of isolate switching to a different thread? Realistically we are keeping isolate/(vm)thread affinity, so switching should not happen.

[mraleph]

It is not related to moving between threads at all. ScopedThreadLocal are valid within the scope of synchronous execution (hence the name). So if you do stl.use(f) or stl.with(value, f) once synchronous execution of this expression completes stl (e.g. use or with completes) is unbound.

[aam]

I was curious about the case when f is asynchronous. Would that result in ScopedThreadLocal values bound only for initial synchronous part of f execution? In the example above - before await Future.delayed(Duration(seconds: 10));?

[mraleph]

cc @alexmarkov for memory model feedback

[mraleph]

Pushed updates based on @aam and @lrhn comments.

PTAL