Add --regextype=RE2|EXACT: -grep literal vs regex mode (#99)

[helly25]

First -grep enhancement (#99), and the answer to your "exact vs regex" requirement: a --regextype global that selects how -grep reads its pattern.

• --regextype=RE2 (default) - RE2 regex, as shipped.
• --regextype=EXACT - literal substring per line, so . is a literal dot and a pattern that isn't valid regex (foo(bar) is a fine literal.
• MATCH (grep/BRE flavor) and PCRE - reserved for refactor(printf): dispatch -printf directives and escapes via constexpr LimitedMaps #85; refused now with a clear usage error (exit 2), as is any unknown value.

$ xff data -grep '3.50'                 # RE2: '.' is a wildcard
data/p.txt:1:price 3.50
data/p.txt:2:price 3X50
$ xff --regextype=EXACT data -grep '3.50'   # EXACT: literal dot
data/p.txt:1:price 3.50

Wiring: run.cc ResolveGrepLiteral (RE2→false, EXACT→true, MATCH/PCRE/unknown→InvalidArgument refused before the walk) threads EvalContext::grep_literal; EvalGrep branches to a literal StrContains instead of the pre-compiled RE2 matcher, so EXACT never depends on the pattern being a valid regex. -content/-rxc and find's own positional -regextype primary are untouched - per the dash-count convention --regextype is the xff global superset; #85 unifies them.

Self-doc: --regextype in globals.cc + kHelpText; design.md -grep note updated to "shipped RE2|EXACT". Tests: evaluate_test (EXACT literal dot + regex-metachar-as-literal), run_test (EXACT vs RE2 default, reserved value is a usage error), grep_test.sh e2e. bazel test //... green (39).

Next in #99: -grep=FORMAT custom template with {line}/{text} fields.