Add a new pattern config format

[DannyBen]

This change introduces a pattern-based configuration format for Completely.

The original flat and nested formats remain supported, but pattern config is the
recommended format for new completion files.

Flat and nested config describe completions as pattern-to-suggestions rules:

mygit status*--branch:
- $(git branch)

Pattern config describes the command shape more directly:

patterns:
  - mygit status|st [status options]

options:
  status:
    - --branch|-b <branch>

tokens:
  branch: $(git branch)

The difference is that flat config describes when to suggest words, while pattern config describes commands, options, option values, and positional values.

Improvements

Positional Args Are First-Class

Pattern config treats positional arguments as named values with a position in the command line:

patterns:
  - cli clone <source> <dest>

This lets completion distinguish between different positional slots. For example, the completion source for <source> can be different from the completion source for <dest>.

The final positional can also be marked as repeatable:

patterns:
  - cli upload <file>...

Only the final positional may be repeatable.

Flags Can Be Interleaved With Positionals

The generated completion script can ignore flags and flag values while calculating the current positional index.

This allows command lines like this to complete correctly:

cli clone -v source1 -p ssh dest1

In flat config, this kind of stateful positional handling requires many wildcard patterns, and quickly becomes difficult to maintain.

Options That Consume Values Are Explicit

Pattern config lets options declare that they consume a value:

options:
  status:
    - --branch|-b <branch>

This gives the generator useful information:

• --branch and -b are aliases for the same option.
• The word after either option should complete branch values.
• The consumed value should not be counted as a positional argument.

Options Are Unique By Default

Pattern config treats each option entry as one logical option. After a non-repeatable option is used, neither that option nor its aliases are suggested again. This keeps generated completions from repeatedly offering flags that should normally appear only once.

options:
  status:
    - --branch|-b <branch>

If an option can appear more than once, it can be marked as repeatable:

options:
  status:
    - --tag <tag> (repeatable)

Repeatable options are suggested again after they are used, including after their value has been completed.

Aliases Are Grouped Naturally

Command aliases and option aliases can be written together:

patterns:
  - mygit status|st [status options]

options:
  status:
    - --branch|-b <branch>

This avoids duplicating parallel flat-config entries for each alias.

Option Groups Are Reusable

Pattern config supports named option groups:

patterns:
  - mygit [root options]
  - mygit status [status options]

These groups keep the file compact while preserving useful structure for the generator.

Token Sources Are Reusable

Completion sources are defined once under tokens and referenced from patterns or options:

tokens:
  directory: +directory
  branch: $(git branch --format='%(refname:short)' 2>/dev/null)
  format: [short, long]
  literal: ++file

This reduces repetition and gives each completion source a stable name.

Token sources use explicit syntax: +directory uses a Bash built-in completion action, ++file means the literal value +file, and a null token source means the token exists but has no suggestions.

Broken References Are Validated

Pattern config validates references before generating a script:

• [status options] must exist under options.
• <branch> must exist under tokens.

This catches common typos early instead of generating a broken completion script.

Better Fit For Bashly Conversion

Bashly already models command-line interfaces in terms of commands, aliases, flags, flag arguments, positional arguments, and allowed values.

Pattern config maps more directly to those concepts than flat config. Bashly now emits this format from its completion builder, including command aliases, option groups, global flags, repeatable flags, repeatable positional args, allowed values, and completions sources.

Better Extension Point

Pattern config provides explicit places for future completion features without adding more wildcard conventions to flat config. Examples include:

• hidden options
• descriptions
• per-token metadata
• shell-specific behavior
• richer positional metadata

Summary

Flat config is close to generated output: when the command line matches a string pattern, suggest a list of words.

Pattern config is closer to source intent: a command accepts these commands, options, option values, and positional values.

That lets Completely reason about the command line instead of only matching strings.