Add user-defined compound types + “quirks” (structural interfaces) with C vtable/function-pointer codegen #61

Is your feature request related to a problem? Please describe.
Right now Fun only supports builtin primitive types (e.g. num/dec/str/bin/chr) and arrays, so there’s no way to model real domain objects (like points, config records, etc.) as a single typed value. This forces users to pass around many parallel variables, or encode structure manually, which is error-prone and makes APIs harder to use.

Similarly, there’s no interface/protocol mechanism to express “this type can do X” in a type-safe way, so reusable polymorphic APIs are difficult without dropping to raw C patterns.

Describe the solution you'd like
Add first-class user-defined compound types plus interfaces (called quirks) that compound types can implement.

1. Compound types syntax
   Support defining named compound types like:

compound Point {
  dec x, y;
  str title;
}

• Fields are statically typed.
• Multiple fields of same type can be declared on one line (dec x, y;).
• Instances should be passable as values, storable in variables, and usable as function parameters/returns.

2. Quirks (interfaces) syntax
   Support defining quirks like:

quirk Writeable {
  some_fun() num;
  fun1();
  // or: fun1() void;
}

• A quirk declares a set of required functions (signatures only).
• Allow explicit void return type, and keep fun1(); as shorthand for fun1() void; if that matches the language direction.

3. Implementing quirks
   Allow compound types to implement quirks, and enforce that implementations match the declared signatures.

4. Structural equivalence for quirks
   Quirk “type identity” should be structural: two quirks with the same required function signatures should be considered the same contract even if the quirk names differ. (I.e., matching quirk implementations should be of the same type even if they are named differently.)

5. C codegen approach (robust + safe C)
   For code generation to C, represent quirk-typed values using function pointers (vtable-style), so calling quirk methods compiles down to indirect calls through those pointers. The goal is for Fun to remain easy to use while producing robust, safe-ish C output (as safe as C can be), without relying on fragile name-based hacks.

Additional context

• Example intent: define a Point record with fields and optionally make it “writeable” via a quirk so generic functions can accept anything implementing that quirk.
• Preference: keep this feature orthogonal to existing primitives and avoid breaking existing code; errors for missing/incorrect implementations should be clear at compile/typecheck time.
• Codegen note: using function pointers implies needing a stable representation for “a value + its quirk method table” (likely a struct holding void* self plus function pointers), and method calls become tbl->fun1(self, ...) style in emitted C.