fix(status): rudimentary support for filenames with spaces

[claytonrcarter]

The regex in StatusEntry::try_from() was mistaken parsing status lines for files with spaces in such a way to discard the first word in the path name. This attempts to make that less likely by making the regex more specific, but I don't think it's really unavoidable without completely reworking this part of the code to be less flexible. eg if we parsed each of the 1/2/u statuses separately, then we could be more specific about how many fields we need to match/capture for each option.

I suspect that this issue was already rare, and that this fix will make it even moreso. Given that, I feel like a more robust/complex fix probably isn't warranted. With this fix, files like "r101 project.txt" or "Coffee notes.txt" will work, but "R101 project.txt" or "coffee notes.txt" ("R101" looks like a "change score", and "coffee" is a valid hex value.) (Edit: 🤦 coffee is not a "hex word"; c0ffee is, though.)

The options that come to mind to tighten this up further:

• parse each 1/2/u status separately, making field counts and patterns more discrete
• require a minimum number of chars in an object ID (on my Mac, the longest "hex word" in /usr/share/dict/words is 7 chars, so requiring at least 8 chars in an OID would eliminate "coffee"-style false positives)

[arxanas]

Thanks!