cache tty_width to avoid calling ioctl in a loop and handle cases when stdout is not a tty.

if p->done goes up, way over p->max, we end up with perc being > 100. in this case, reporting the correct percentage is fine, but drawing a bar larger than the screen is not. The bar could still "overflow" and occupy a second line, but only if the percentage number takes more then 4 digits, so it's unlikely.

Walk can be successful in various conditions where cd has to fail. For instance, we may have reached a file or we couldn't walk all the required components. In these "soft-fail" cases, the walk has mutated the fids, so to abort the cd we have to do a walk using a second fid and then clunk the old or new one depending on if it was _completely_ successful or not. Another option may be to track the number of walked path and attempt to walk '..' the right amount of times, this would saves a Tclunk in the case the walk succeeded and require a slightly bigger 9P packet to be sent in the failure case. It would complicate the walk_path API though, so I've not chosen this option.

- looking for Terror doesn't make sense, it's Rerror - consume the tag before reading the error string

to implement the get command: - implement do_stat and do_read - implement a simple progress bar