Outline of structs as a general 'definition' system

[flyingsilverfin]

Usage and product changes

We introduce the architecture around structs definitions, and definitions in general.

The idea of a definition is that it is a general schema construct outside the regular thing and type system - this will initially be used for structs and functions.

Definitions are interesting because their interesting payload is in the value, not the key. However, the key contains the ID of the definition. As a result, you can consider the new DefinitionKey to be analogous to TypeVertex, but the interesting data structure is the StructDefinition, which serialises a struct's content.

In doing this, we also realise that ValueType must encompass the built-in value type category, plus the ID of the struct definition, and create a new ValueTypeCategory which can map to a Prefix and doesn't contain the ID of struct definitions. Lastly, we create a the serialised form of ValueTypeBytes, which is used as the property of an attribute type's value type, including the definition ID if it exists.

What isn't implemented yet:

1. The indexing + retrieval by name of value types through the TypeManager
2. Serialisation of StructDefinition
3. The data insertion and deletion pattern of struct instantiations

[vaticle-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• [ ] This change is trivial and does not require a code or architecture review.

Code

• [ ] Packages, classes, and methods have a single domain of responsibility.
• [ ] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [ ] The code is canonical and the minimum required to achieve the goal.
• [ ] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [ ] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [ ] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [ ] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [ ] Any required build and release automations are updated and/or implemented.
• [ ] Any new components follows a consistent style with respect to the pre-existing codebase.
• [ ] The architecture intuitively reflects the application domain, and is easy to understand.
• [ ] The architecture has a well-defined hierarchy of encapsulated components.
• [ ] The architecture is extensible and scalable.