feat: add Alias option for reusable named grammar fragments

[Pastalikek65]

Closes #22

Adds participle.Alias(name, grammar) — named, reusable grammar fragments referenced from struct tags as <name>:

participle.Alias("jqName", `"@" @Name ":" @Name`)

type parser struct {
    JQ qName `"@" @Name ":" @Name`
}

parser, _ := participle.Build[grammar](
    participle.Alias("delim", `"|"`),
)

type grammar struct {
    A string `@Ident <delim> @Ident`
    B string `<delim> @Ident`
}

Design

• Non-capturing: aliases match literal and named-token patterns and compose with the normal tag operators (? * + !, groups, disjunction), but cannot bind values. Captures (@ and @@) always target a struct field of the surrounding production — an alias has no field, so @/@@ in an alias body is rejected at build time with a clear message (aliases cannot capture (@); move captures to a struct field). This avoids the index-out-of-range panic that naive attempts hit during development.
• Syntax: <name> in parseTermNoModifiers (grammar.go), resolved from generatorContext.aliases. < was otherwise unused in the tag grammar, so no ambiguity with named token references.
• lexStructFromTag (struct.go): a bare grammar string is lexed without a backing struct type.
• Alias errors (unknown reference, duplicate name, empty name, invalid grammar) fail at build time.

Tests

10 tests: literal patterns, alias reuse across fields, multiple aliases, ? modifier, @/@@ rejection, unknown reference, duplicate, empty name.

One open question for maintainer: whether aliases should be capturing by binding to an implicit "value" the referenced field receives (e.g. a special syntax <name> meaning the fragment's captures flow into the field). This would require threads of field context through alias resolution beyond build time; offered as a follow-up rather than blocking this PR.