Revert Ref.read Ref.write to untracked because they're shared between IO and Scope interfaces.

[ChrisPenner]

Overview

When adding the new Ref instructions I had incidentally changed Ref.read and Ref.write from Untracked -> Tracked;
This caused tests in base to fail because they're triggering sandboxed IO detection.

In theory operations on Ref IO should be tracked and on Ref Scope should be untracked, but since they both use the same builtins underneath that's not currently possible.

This PR reverts the tracking to this state:

Untracked "Ref.read" 
Untracked "Ref.write" 
Tracked "Ref.readForCas" 
Tracked "Ref.Ticket.read" 
Tracked "Ref.cas" 

Which seems a bit strange, but is the most conservative we can make it at the moment.

It's notable that readForCas, Ticket.read and Ref.cas only apply to IO refs anyways, but weirdly Ticket.read doesn't actually have IO in its type even though it uses IO in the runtime implementation and is marked as Tracked.

The logic for now is just to revert it to what we had before 🤷🏼

Implementation notes

Swap the tracking back to its previous state

Test coverage

• run the base tests.

[ceedubs]

weirdly Ticket.read doesn't actually have IO in its type even though it uses IO in the runtime implementation and is marked as Tracked

That does sound a bit suspicious. @SystemFw and @dolio was that an intentional choice?

[SystemFw]

I don't think it should have IO in its type, it's basically an immutable Box. Can you point me to where it uses IO in its implementation?

[ChrisPenner]

@SystemFw ah, never mind, I was mistaken 👍🏼