Add WAL TypeSpec generation

[adsharma]

Fixes: #404

Summary

• add a TypeSpec/Jinja-based WAL record generation scaffold
• add one TypeSpec declaration per WAL record plus shared generator templates
• document ValueVector and manual-record handling

Manual Generation

• AlterTableEntryRecord

  • src/include/storage/wal/record/alter_table_entry_record.h
  • src/storage/wal/records/alter_table_entry_record.cpp

• CreateCatalogEntryRecord

  • src/include/storage/wal/record/create_catalog_entry_record.h
  • src/storage/wal/records/create_catalog_entry_record.cpp

Their polymorphic payload serialization is emitted from special branches in wal_record_header.h.j2 and wal_record_source.cpp.j2

Validation

• make shell
• wal_test and transaction_test

[adsharma]

For our WAL case, generalizing polymorphic payload serialization would take three pieces:

1. Describe the variant payloads in TypeSpec:

  @discriminated(#{ discriminatorPropertyName: "alterType" })
  union AlterExtraInfo {
    addProperty: AddPropertyInfo,
    dropProperty: DropPropertyInfo,
    renameProperty: RenamePropertyInfo,
  }

2. Teach generate_wal_typespec.py / templates how to map that union to C++:

  switch (alterInfo->alterType) {
  case AlterType::ADD_PROPERTY:
      ...
  }

3. Add serialization policies for non-regular fields:

• how to serialize variant tags as existing C++ enums, not strings
• how to serialize payload fields that call custom methods, e.g. PropertyDefinition::serialize
• how to deserialize into std::unique_ptr
• how to map variants to concrete C++ classes like BoundExtraAddPropertyInfo

So TypeSpec can represent the shape, but it won’t automatically know Ladybug’s C++ factory/ownership conventions. The useful next step would be adding a small WAL-specific metadata layer for discriminated payloads rather than hardcoding AlterTableEntryRecord and CreateCatalogEntryRecord branches by record name.