Improve error reporting

[Johan-Liebert1]

Error reporting right now is pretty sub optimal which makes tracking down the exact source pretty cumbersome. Case in point, the following error

Error: Directory entry "grpc" does not exist

is caused by

    #[error("Directory entry {0:?} does not exist")]
    NotFound(Box<OsStr>),

The above error value is used in multiple places, six to be exact, which demands checking all of said places.

We should use fn_error_context::context to have additional information on the error source.

[allisonkarlitskaya]

Very much in agreement. But we should also generally be removing anyhow in the library layer

[allisonkarlitskaya]

I keep going back and forth between using thiserror with error enums and just making everything a std::io::Error with a descriptive message...

[jeckersb]

Long-term the ergonomics of thiserror and error enums will be better. Just consider the first time you have to do a giant refactor in the future, you're going to appreciate the compiler ensuring that you're handling all of the error cases properly. Whereas if you shove everything into a std::io::Error you don't get that help from the compiler.

As far as getting improved context, this kinda ties into something Colin mentioned recently. I'd like to see improved usage of tracing over in bootc, and I think it would be good to align composefs-rs as well and have it emit spans and events. Then the consumers of the library can decide how to filter/display events to the users.

[cgwalters]

you're going to appreciate the compiler ensuring that you're handling all of the error cases properly.

IME the 95% case is just propagating via ?. Then 4% is handling "not found" which is exactly this! And so I did #119 for that.