[ASTraitCollection] Convert ASPrimitiveTraitCollection from lock to atomic.

[appleguy]

This resolves a deadlock case, which might be more common with Yoga (unsure): #353 . Fortunately it also simplifies the code.

We should think carefully if there are any transactional locking cases that could cause this to be unsafe. However, I think it has fairly limited usage and is probably appropriate for an atomic.

[Adlai-Holler]

Good change. But with C++ atomics, you can actually use plain old assignment semantics e.g.:

int val = _myAtomicInt;
_myAtomicInt = 5;

I think we should prefer this style since it's so much prettier. Agree?

[appleguy]

@Adlai-Holler oh wow, does this mean that ASLayoutElementStyle can also do that? I didn't know this worked, presumably operator overloading to call .store() for you.

Sure, I'll change it.

[garrettmoon]

Seems safe overall to me. One concern I have is fragmentation of property locking without a cohesive documented strategy.

[appleguy]

@garrettmoon yeah, that's a good point and something we should talk more about strategically. I think we need to do some high level data flow analysis and make a call such as flags and a small number of other properties maybe are OK to use atomics, but even that could potentially need value-capture at the beginning of locking scopes that use the flag multiple times (this is rare but can happen)