Need to setup re-creatable fuzzers for anything that has a set of any
kind. For example, is.WS has quite a few different combinations.
Something like scan.Expect(is.Opt{is.WS},"foo",is.Opt{is.WS}) has
several hundred possible combinations.

Since Bonzai's focus is on rapid development and clean code I'm making
the default import package name Z (instead of bonzai). The likelihood
of people having package naming conflicts with a capital Z is very
unlikely and anything that does can set the prefix to something else.
Basically, I want the default to be as easy to use as possible. Go
formalists will scream at me for this, but I don't give a fuck.

Need to add init() terminal color support detection and equivalents of
all esc constants in order to manage terminal state better.

We want to reserve the maps subpackage for nothing but map functions so
people can peruse it for map functions they might need and not want to
rewrite. This also gives a good overview of how to use map functions.
Anything that is not a map function should find another home.

After reaching the leaf completion continually tapping tab keeps adding
the last completion leaf item to the end of the command line. We need to
trap this from happening.

Need a command that can use reflection on imported Z.Cmds and see if
they have everything they need. Avoid the temptation to do this every
time Run is called.

Should look at Version detect an VERSION file within the Source URL
location making intelligent decisions about the Source URL expansion
required by the hosting service (github.com, for example). If not
VERSION file is found and the service is github.com use the GitHub API
to determine the latest release. It is important that there be no
dependency on Git for checking for a latest version allowing
distribution of binaries to take place on a simple web server with a
VERSION file next to the binaries.

When tab completion happens the ! characters and such need to be
escaped. But this will depend on the shell environment, but since
COMP_LINE will never be set for anything but bash we are good to assume
it.

Since documentation is a core value proposition from Bonzai, we need to
really create a formal specification (PEGN), parser, and AST for the
unique (but compatible) bonzai.mark language. Creating an AST is
essential for Cmd creators who want to create views of the documentation
in other formats besides text, such as from a local web server.

Go has no standardized way to test the compiled commands (focusing
instead on functions and methods). While this is fine for most
applications development, Bonzai developers have a consistent need to
test every possible command line invocation or their final commands
(post compilation). The usual tricks to get os.Args[0] and run that
seem clunky and inconsistent. Something more is needed.

The need for a custom solution is increased when considering that
examples of command line usage are a fundamental part of the
documentation and regularly are buggy in the docs. So any test solution
must incorporate the ability to embed the runnable tests into the
compiled binary so that they are available with foo help examples.

In fact, why not give them unique names and allow the examples to be run
from the command line by adding run after the name (foo help example bar run).

The cmd.Shell should create a rich-terminal interactive shell that
contains help information and a prompt with tab completion. This will
ease the pain of using Bonzai commands where complete -C foo foo
support is not enabled (including inferior shells like zsh, fish,
powershell).

Examples are the most important part of the documentation and they
already have to be created as unit tests anyway. So we need to create a
generator directive that grabs them from the examples_test.go files
when the command is compiled and embedded. In fact, we can simple embed
the examples_test.go file itself and add the code to cmd.Help to
open it and parse the essential parts of it and transform it exactly as
the unit test reflection method uses.

At long last I've seen the light. It was always grating on me that
Expected used so much unnecessary functional recursion. Using simple
scanner methods that panic is easier to write and maintain, faster,
cleaner, and just as easy to generate from PEGN. I'll still keep the
one-to-one parity with PEGN and read a comment to associate a given
method with a specific ID from PEGN. First I'll factor into methods,
then I'll write the method generator, then we'll write the reverse to
PEGN generator.