Advanced error handling

[naure]

Introduce a library that makes error handling more convenient and reports more debug information.

• Currently anyhow is used in some places like ceno_emul. Another good choice is eyre. Pick one.
• Revisit existing error types (ZKVMError) and add context or backtraces.
• Revisit core code that has only error messages but should use error types.

[matthiasgoergens]

Keep in mind that we should only bother with something like eyre (or even Result) for conditions we can actually do something about. Eg if a file we want to read from doesn't exist or so.

Problems like underconstrained constraints are logically more like type errors, because they would happen to the program regardless of actual inputs. Rust's type system just isn't strong enough to turn them into compile time errors, so we need to run the program. See eg #466

But the only thing we can really do for these errors is abort with an error message. So we don't need to introduce unnecessary complexity for these in trying to pass them around before we abort with the error message.

In contrast, a proof failing verification is an error we can treat with eyre or similar. It's a condition that we expect to happen at runtime from time to time, depending on input.