docs: add comprehensive API design review for v2.0 to v2.1 evolution

This commit introduces a detailed API design review document that
analyzes the current cmdguard v2 API and proposes improvements for
v2.1.0, based on research on Go SDK/library best practices, samber/do/v2
integration patterns, and project-specific coding standards.

Key additions:

1. New documentation file (docs/API_DESIGN_REVIEW.md):
   - Executive summary with prioritized findings
   - Comprehensive research on Go API design best practices:
     * Functional options pattern
     * Error handling with errors.Is/As
     * Type-safe enums
     * Generics vs interfaces decision matrix
     * Anti-patterns to avoid
   - samber/do/v2 integration patterns:
     * Package function pattern
     * Optional DI approach
     * Interface binding for extensibility
     * Scoped services and lifecycle hooks
   - Current cmdguard v2 API analysis
   - Identified issues and recommended improvements:
     * Remove redundant F type parameter from GuardedCommand[T,F]
     * Rename GuardedCommand to CLI for clarity
     * Make DI optional (opt-in via WithDI())
     * Eliminate any type usage in NewFlagRegistry
     * Add Package() function for samber/do integration
   - Proposed API surface with detailed signatures
   - Migration guide from v2.0 to v2.1
   - Implementation checklist with phases

2. pkg/cmdguard/v2/flags.go:
   - Split uint/uint64 handling in registerFlag switch
   - Add addUint64Flag method for uint64 flag type support
   - Use pflag.Uint64P/Uint64 for proper flag registration

3. pkg/cmdguard/v2/flags_parse.go:
   - Split uint/uint64 handling in parseAndSetValue switch
   - Add parseAndSetUint64 method for uint64 value parsing
   - Use strconv.ParseUint with 64-bit precision

Rationale:

The uint64 type was being grouped with uint in the switch statements,
but these are distinct types in Go's reflect package. While they often
work interchangeably in practice, separating them ensures proper type
handling and aligns with Go's type system precision requirements.

The API design review document serves as a roadmap for future v2.1.0
development, providing evidence-based recommendations backed by:
- Industry best practices from popular Go libraries
- samber/do/v2 official documentation
- Project policy compliance (HOW_TO_GOLANG.md)
- Analysis of current API pain points

Impact:

- Documentation: Adds 1600+ lines of detailed API research and planning
- Type Safety: Proper uint64 type handling in flag registration/parsing
- Future Development: Clear path for v2.1.0 API improvements
- Breaking Changes Preview: Documents planned breaking changes for v2.1.0

Testing:

Existing test suite validates flag registration and parsing for all
supported types. The uint64 handling follows the same pattern as other
numeric types.

References:

- docs/API_DESIGN_REVIEW.md: Complete analysis and recommendations
- Go API Design: https://go.dev/blog/effective-go
- samber/do: https://github.com/samber/do
- Functional Options: https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis

💘 Generated with Crush

Assisted-by: GLM-4.6 via Crush <crush@charm.land>

Author: LarsArtmann