+ I wonder if some kind of `-fast-compile` would be possible? By default I
  iterate over all definitions in a scope, but an idea for a future rewrite
  could be to start from main() and typecheck on demand, leaving untouched bits
  of code unchecked. Unsure how much time it would really save, but we could
  also add some kind of warning like `function never used` by later iterating
  over the unchecked stuff? In general I don't like how `actualize.c` works atm,
  at least generics instantiation (in particular the unification is currently
  annoying as fuck to deal with)

+ Currently the codegen is kind of bugged in that struct instances use the
  functions defined in the scope of the public part of the chain, one 'shortcut'
  would be to require that 'continue' matches the pub/private of the base
  struct, so public structs can only be continued publically and private structs
  privately? See `tests/struct_priv_trait_cont` for an example.

+ Build the consteval stuff

OPTIMIZATIONS:
+ Use hashmaps or something similar for lookups for types and calls

LOWERING:

Structure handling in lowering could probably be as follows:

Imagine
struct something {
	i27 a;
	other_struct b;
};

main ()
{
	// something s = {...};
	i27 s_def = alloc $STRUCT_SIZE;
	// i27 a = s.a;
	i27 member_a = struct_def + 0;
	i27 a << struct_def 0;

	// other_struct c = s.b;
	i27 c_def = alloc $OTHER_STRUCT_SIZE;
	i27 member_b = struct_def + 3;
	c_def blit member_b, $OTHER_STRUCT_SIZE; // has to be added to qbt,
						 // might need to be handled
						 // like store with constant as
						 // 'return'. Or can c_def be
						 // considered an output value
						 // for blit?

	/* calls just dump all registers down I guess, as do returns. No
	 * implicit conversion to pointer and passed as first argument, ufcs
	 * does that for us. */
}

+ Might want to add in some kind of suffix for integer types, s for i9 and l for
i27 or something?

+ lowering could check if a function has been lowered and if not, lower it for
us. Should it also check that no abstract data types are used in the final
lowering? Which would mean that even the lowering is allowed to fail, and not
just the actualization phase.

+ continue/break could probably fairly easily use labels as well, just check
that the following AST node is a loop and treat is as the name for that loop.
Then continue just goes to the bottom of the loop and break goes out of the
loop, pretty much what we're currently doing but just with the top loop
in the stack. We'd probably just have to check the loop stack in lower.c,
should be fairly straightforward?

+ Function callbacks currently aren't treated as pointers, even though they
really are under the hood. Unsure if I want to do something about it, one option
could be to treat callbacks as their own thing but allow them to be casted to
pointers?