Core namespace for handling views.

See README for an overview.

Base64 encoding and decoding.

Translating a buffer into a Base64 string is useful for those places which
do not understand buffers natively (eg. JSON).

Buffers are the platform representation of a byte array which can be wrapped in a view
and manipulated by using the core `helins.binf` namespaces. They represent a raw, fixed-size
chunk of memory.

On the JVM, a buffer is indeed a `byte-array`.

In JS, it is either a `js/ArrayBuffer` or its sibling `js/SharedArrayBuffer`.

<!> Stil very experimental, do not use in production <!> 

Interaction with environments that conforms to a C-like ABI.

This namespace is mainly about defining C structures in order to pass them or to understand
them when interacting with native functions. It could be when using JNI on the JVM or when
calling WebAssembly functions in Clojurescript, for instance.

This opens the road to interacting with languages like C++ and Rust since they allow for
defining such C structures and commonly do so in the context of libraries.

BinF already provides utilities for handling arbitrary data in native memory or in WebAssembly memory.
For example, on the JVM, `DirectByteBuffer` implements view protocols and is commonly used with JNI.
Some WebAssembly runtimes such as `Wasmer` use them to represent the memory of a WebAssembly module. In
JS, WebAssembly memories are buffers from which a view can be built.

What is missing is knowing how to use a C-like ABI which relies on following some rules. For instance,
the members of a structure are aligned on specific memory addresses for performance reasons. This namespace
provides utilities for defining such composite data structures as EDN and computing everything there is to compute
for following those ABI rules.

3 definitions are needed for understanding these utilities:

  - An `env` is a map containing information needed for computing those rules such as the alignment being used.
    See [[env]] for creating one.

  - A description map describes either a primitive type (eg. [[u32]]) or a composite data structure (eg. [[struct]]).

  - A description function takes an `env` and produces a description map.

A description map is plain data containing eveything that is needed for handling this type. For instance,
a description of a structure contains computed memory offsets of all its data fields.

This namespace contains ready description functions for primitive types (such as [[f32]]) as well as functions
for creating description functions for composite ones (such as [[array]] or [[struct]]).

See [[struct]] for a small example and a full one in the `helins.binf.example.cabi` namespace from the repository.
Source code also clearly shows what is being outputed. While daunting at first, this namespace is actually quite simple.

Obtaining information about endianess and changing the endianess of primitive integers.

Endianess is either `:big-endian` or `:little-endian`.

Handling floating values, miscellaneous coercions.

`test.check` generators for primitive integers, buffers, and views.

Attention, `test.check` is not included and must be imported by the user.

Handling integers (maximum 32-bits), miscellaneous coercions.

64-bit integers are handled in `helins.binf.int64`.

Handling 64-bit integers, miscellaneous coercions and unsigned math operations.

64-bit integers deserves special attention. On the JVM, there is no explicit unsigned 64-bit
type and in JS, there are no 64-bit integers at all. This is why creating and handling them in
a cross-platform manner, signed or unsigned, is done via this namespace.

On the JVM, unsigned 64-bit integers are actually regular 64-bit signed values but treated differently.
What matters is the bit pattern. For human-readability, see [[str-u]].

In JS, they are `BigInt`, a type which does not even interoperate with regular numbers.

As a rule, all values in any operation must be 64-bit integers since THEY DO NOT MIX with <= 32-bit integers.
This namespace provides functions for logical and mathematical operations for which sign matters (such as [[u<=]]
or [[udiv]]) as well as bitwise operations which need an alternative implementation (such as [[bit-clear]]).

Read and write integers in LEB128 format (as used in WebAssembly or DWARF).

All functions mentioning 64-bit integers takes values complying with the
`helins.binf.int64` namespace.

Contains [[view]] for creating a view over native memory (as opposed to the JVM heap)
as well as utilities for handling raw pointers.

The main utility is [[view]] which returns a `DirectByteBuffer`. Allocating native memory
can lead to performance increase and simplifies things when using tools such as JNI.

Other utilities are related to raw pointers and are DANGEROUS.

Manipulating raw pointers and managing memory is just as error prone as in native programming.
Those utilities are for users knowing both what they want and what it implies. Otherwise,
segfaults are to be expected.

<!> Pointer utilities are still experimental, might change in the future <!>

Protocols related to views.

This namespace should be relevant only if a new type needs to implement those. The common user
should not have to bother.

Those functions are described in the core `helins.binf` namespace as well as in the README file.

Depending on the type, not all protocols must be implemented. For instance, a stream-like type
might not be seekable and might implement only `IRelative*` protocols and not `IAbsolute*` ones.

Decoding a string directly to a buffer and vice-versa.