Implement Wave variant types and exhaustive variant matching

## Roadmap context

This tracks the payload-bearing `variant` type planned for Wave after the current enum and module contracts. Existing `enum` remains an integer constant set and must not be reinterpreted.

## Language contract

```wave
variant Result {
Ok(T),
Err(E)
}

match result {
Result::Ok(value) => { use_value(value); }
Result::Err(error) => { handle_error(error); }
}
```

## Scope

- A distinct variant token, AST node, and type representation.
- Payload-free, single-payload, and multiple-payload cases.
- Generic variant construction and type checking.
- Infinite-size recursion rejection while pointer recursion remains valid.
- Variant patterns, arm-local bindings, nested patterns, and exhaustiveness.
- Control-flow analysis for exhaustive matches.
- Module visibility and private/public lookup.
- Backend layout and code generation without changing existing enum behavior.

## Required diagnostics

Duplicate cases, unknown cases, payload arity/type mismatch, unresolved generics, infinite-size recursion, duplicate patterns, non-exhaustive matches, unreachable wildcard arms, and unsupported ABI exposure.

## Completion criteria

- [ ] Generic `Result` and `Option` work end to end.
- [ ] Existing integer/const/enum match behavior does not regress.
- [ ] Variant values cannot cross a C ABI boundary without an explicit supported contract.
- [ ] Parser, semantic, codegen, and execution regressions cover valid and invalid programs.

Small parser and validation pieces may be filed separately as good first issues.

No specific files or tests are named. Start by mapping the parser, semantic/type-checking, code-generation, and execution components, then split out a small parser or validation piece; completion requires the listed diagnostics and regression coverage without changing existing enum behavior.

Written by the indexing model from the issue text.