Support Nockma/Anoma scry operation

[paulcadman]

Anoma Scry Semantics

The scry OP is represented in Nock using the atom 12. It's purpose is to read from a key-value storage.

The following semantics are deduced from the Anoma codebase:

https://github.com/anoma/anoma/blob/6769dafbe8ef9d9cea1056698a23a6d986f777d6/lib/nock.ex#L142

     s * t1 => t1'   s * t2 => t2'
-----------------------------------------
  s * [scry t1 t2] => read_with_id t2'

Explanation from Ray:

[scry looks like]:

[12 type-info path]

[scry's] semantic is "pull magic data from path", where path is a referentially
transparent key (it's a list of atoms) into the magic data store. in urbit, scry
is a virtual operation implemented at higher virtualization levels of the
system; in anoma it's a "real" operation against the interpreter. it's used to
read data

in the current anoma codebase you can see it used in execution; it does a
blocking read against /[some random id]/key

so execution pauses there until the transaction is ordered, even though it
starts immediately in the mempool

The read_with_id function indeed blocks until the value of the path is returned from storage. If the key is not found it returns an error (i.e crashes).

Juvix support

Users will need to use Scry in their Anoma applications so we need to provide a
Juvix front-end function that compiles to Nockma/Anoma Scry. (It's not clear to me how the user would obtain the id associated with a value or what kind of applications would require this)

We could add a builtin function for this:

type AnomaStorageId (Key : Type) := mk { storageId : Nat ; key : Key }

axiom anomaGet : {Value  Key : Type} -> AnomaStorageId Key -> Value;