Determine (very near) future structure of CLI

[deitch]

The CLI currently is written in bash. This doesn't scale for a bunch of reasons including: weak testability; lack of access to a module ecosystem; poor debugging; distribution headaches.

We have 2 classes of options (interpreted and compiled), with 3 worthwhile options overall:

Option	Class	Pros	Cons
Python	interpreted	Easy integration with HuggingFace library	Assumes the Python toolchain; required Python env
Go	compiled	Easy distribution of single binary; possible integration with Xet library	Harder to take advantage of HF libraries
Rust	compiled	Easy distribution of single binary; easy integration with Xet library	Minimal Rust knowledge among team; more difficult to write system utilities than go

My personal opinion is as follows:

1. If we were solely targeting developers (i.e. people working directly with models, and used to the entire toolset present, I would lean towards Python.
2. Since we want to cover both compilation and inference, developers and production, we should do a compiled single-binary solution.
3. We can fork out to execute python for HF if needed, or use some of the many HF go dk's; as long as the transport and cache are 100% HF compliant, it doesn't matter.
4. It doesn't matter if we do go or rust, but it is easier to find go-skilled folks than rust, so we should do go

[deitch]

cc @jerenkrantz @rvs