Status refactor

[mroth]

As per #93, scmpuff needs substantial cleanup. A big part of this is in the status command, where much of the complexity of the internal code lies. In current state, it is very difficult to understand what most of the code is doing and why it was written that way.

As an explainer: Much of the code for the status command was originally written in the Go version 1.3 era, by someone who was brand new to Go (me), and intended as a quick and hasty direct port of the sum_breeze Ruby scripts. While a detailed integration testing framework was later added to preserve reliability, much of the status code still reflects the conditions in which it was originally produced, and it makes it very difficult to reason about a larger refactoring.

This PR is from a branch where I am plucking away at tiny changes bit by bit to make the code more readable and better structured, so that it's even possible for future refactorings to change functionality.

Thus, it's primarily intended as a cleanup, prior to a large scale refactoring to change underlying behavior.

[!NOTE] Expect many, not well reasoned commits. A lot of this is making tiny changes in the margins of my spare time (when I'm on hold during a phone call, etc), just chipping away until some structure reveals itself. There will definitely need to be a commit squash when we approach something resembling mergeable. Expect frequent force pushes.

[mroth]

Documenting work thus far:

Code cleanup:

• 🧼 Random collection of dozens of small, quality of life code changes for documentation and readablity.
  • While certainly not at the level of code hygiene I'd consider baseline today, some of the most egregious crimes against readability have been improved at least.

Refactoring:

• 📦 Began to rationalize out git status representation (gitstatus package) and parsing of porcelain git status output (gitstatus/porcelainv1).
  • This paves the way for beginning to introduce alternative providers of git status information, such as go-git (#33) or writing a --porcelain=v2 parsing package.
• 🌈 Refactored color handling.
  • Replaced the previous approach with ANSI codes strewn across UI strings in the codebase (where I didn't even understand the original strings, as they were directly copied and pasted from scm_breeze). Now we just have a few constants in a file and some lookup tables.
  • It's simple enough that it might not even be worth doing #28 at this time, color support could be locked down for Windows by simply implementing go-colorable and the isatty packages.

Test improvements:

• 🥇 Golden file testing for porcelain=v1 parsing.
  • Combined with the new experimental dumptool (see below), we now have a hugely more reliable and reproducible way to test parsing of various git working tree statuses.
  • This should make implementing new status codes (such as in #86) much easier to do a controlled fashion.
  • Note: The corpus of testdata here still needs to be expanded with a wide variety of repository states. Probably best left to a separate issue for user contributions.
• 🥇 Golden file testing for scmpuff status output rendering.
  • This is significantly faster and more reliable than the previous methodologies, and runs alongside the unit tests, and should allow for more fearless future refactorings of the scmpuff status output (the implementation of which is still a legacy porting mess.)
• 🗃️ Improved unit tests for file path management across different operating systems.

[!NOTE] Between the two golden file test implementations above, a nontrivial chunk of the old Ruby Cucumber/Aruba based e2e integration tests in command_status.features that are focused on the parsing and then subsequent display of a repo could likely be replaced with targetted unit tests. I didn't take this on as part of this refactor, but this could be a GOOD_FIRST_ISSUE for someone looking to contribute to this project.

New functionality:

• 🥟 Added experimental dumptool utility (internal/commands/status/dumptool):
  • Provides debugging and analysis tools for git status information, allowing easy creation of an archive of relevant data to reproduce any git status issues on a given repository. These files can be near direct input for the new golden file tests.
  • Not yet integrated into the scmpuff CLI, but likely should be made user facing in the next release (via something like scmpuff status --debug-dump), just looking for a bit of testing and feedback first.

[mroth]

Out of morbid curiousity, going to click the Codepilot code review button on this PR...

[mroth]

There are follow-on tasks for certain (as mentioned in the summary), but I believe this is now in a good enough state to be merged, and it should make it easier for contributors to do future work.