Constructors for CVM cells and related type predicate functions.

Interacting with a peer via the binary protocol.

After creating a client with [[connect]], main interactions are [[query]] and [[transact]].

All IO functions return a future which ultimately resolves to a result received from the peer.
Information from result can be extracted using:

- [[error-code]]
- [[trace]]
- [[value]]

Code execution in the CVM, altering state, and gaining insights.

Central entities of this namespaces are contextes and they can be created using [[ctx]].

All other functions revolve around them. While the design of a context is mostly immutable, whenever an altering function
is applied (eg. [[juice-set]]) or code is handled in any way (eg. [[eval]]), old context must be discarded and only returned
one should be used.

Cheap copies can be created using [[fork]].

Actions involving code (eg. [[compile]], [[exec]], ...) return a new context which holds either a [[result]] or an [[exception]].
Those actions always consume [[juice]].

Given that a "cell" is the term reserved for CVM data and objects, execution consists of following steps:

| Step | Function | Does |
|---|---|---|
| 1 | [[expand]] | `cell` -> `canonical cell`, applies macros |
| 2 | [[compile]] | `canonical cell` -> `op`, preparing executable code |
| 3 | [[exec]] | Executes compiled code |

Any cell can be applied safely to those functions, worse that can happen is nothing (eg. providing an already compiled cell to
[[compile]]).

If fine-grained control is not needed and if source is not compiled anyways, a simpler alternative is to use [[eval]] which does
all the job.

When a CVM instance is used, it relies on a thread-local database which can be manually retrieved using [[local]].

The thread-local database can be set usint [[local-set]]. Originally, at thread initialization, it corresponds to
the [[global]] database which is common to all threads. Its value can also be altered using [[global-set]].

Ultimately, the [[global]] database itself returns [[default]] unless user has set its value to another database.

Default [[database]] is an Etch instance. See [[convex.db]].

Etch is a fast, immutable, append-only database specially tailored for cells.

This namespace provides an API for creating an instance by pointing to a single file. This file
hosts an arbitrarily large map of `hash of the encoding of a cell` -> `cell`. Hence, reading require
hashes (see `convex.cell/hash` from `:project/cvm`) and writes primarilty return refs or nil
when not found (see [[convex.ref]]).

Lastly, a root hash can be stored and retrieved. Cell stored at root is typically used to maintain
some sort of global state or table tracking what is needed.

**Attention.** By default, R/W functions use the current thread-local database (see [[convex.cvm.db]]).
Providing an instance explicitly is tricky because when reading, not all data might be retrieved at once.
This is what allows large data, even larger than memory, to be queried: large structures are split into refs
and not all refs are necessarily resolved right away. However, any unresolved ref will be resolved against
the current thread-local database when needed, not the one that was explicitly provided when reading.

In other words, when handling a custom instance, it is best to work on a dedicated thread and call
[[convex.cvm.db/local-set]].

That being said, instances support multithreading. Being immutable, no thread has to worry that some data might
be removed or updated in place.

Creating and managing a key store for storing key pairs in a file.

See [[convex.sign]] about key pairs.

Reading, parsing various kind of sources into CVX cells without any evaluation.

Attention, currently, functions that read only one cell fail when the input contains more than one.
In the future, behavior should be improved. For instance, consuming cells one by one from a stream.

Also see the [[convex.write]] namespace for the opposite idea.

A `ref` is a reference to a cell. Most of the time, is it used as an intermediary value between a database
and the CVM. Unless refs are handled in reference to an explicit database, database used when resolving is always the current
one bound to the local thread. See [[convex.cvm.db]], [[convex.db]].

A **direct ref** holds a direct reference to a cell whereas a **soft ref** might release its reference when there is pressure
on memory. If needed, a **soft ref** will fetch its corresponding cell from a database.

Creating a peer which can either:

- Run alone for dev and test
- Run locally, synced with other local peers
- Run locally but synced with the test network on `convex.world`

Examples are provided in README.

Signing cells using public key cryptography, most notably transactions as required prior to submission.

More precisely, is signed the hash of the encoding of the cell, producing a signed data cell.

Uses Ed25519.

Writing, encoding CVX cells various kind of sources.

Binary is big-endian and text is UTF-8.

Also see [[convex.read]] for the opposite idea.