humility formats `anyhow` errors with backtraces, which is confusing when also displaying a Hubris stack trace

When running humility tasks <TASK> --stack on a dump of a task that overflowed its stack, Humility prints an error indicating that the stack pointer points at an invalid memory address (which makes sense, as it points outside of the dumped region), and suggests the use of the --guess flag to try and reconstruct the stack trace from the frame pointer. This error is represented by an anyhow error, which includes a backtrace:

eliza@theseus ~/Code/oxide/hubris $ humility -d hubris.core.packrat.0 tasks packrat --stack
humility: attached to dump
system time = 321850
ID TASK                       GEN PRI STATE
11 packrat                      0   1 FAULT: stack overflow; sp=0x24001f98 (was: ready)
   could not read registers: read of 32 bytes from invalid address: 0x24001f98

Stack backtrace:
   0: <humility_core::dump::DumpCore as humility_core::core::Core>::read_8
   1: humility_core::hubris::HubrisArchive::registers
   2: humility_cmd_tasks::print_tasks
   3: humility_cmd_tasks::tasks
   4: humility_cmd::attach
   5: humility::cmd::subcommand
   6: humility::main
   7: std::sys::backtrace::__rust_begin_short_backtrace
   8: std::rt::lang_start::{{closure}}
   9: std::rt::lang_start_internal
  10: main
  11: __libc_start_call_main
  12: __libc_start_main_impl
  13: _start
   use `--guess` to guess at stack trace

When the command is run again with --stack --guess, Humility still points the error, along with the Hubris backtrace that it guessed at:

eliza@theseus ~/Code/oxide/hubris $ humility -d hubris.core.packrat.0 tasks packrat --stack --guess
humility: attached to dump
system time = 321850
ID TASK                       GEN PRI STATE
11 packrat                      0   1 FAULT: stack overflow; sp=0x24001f98 (was: ready)
   could not read registers: read of 32 bytes from invalid address: 0x24001f98

Stack backtrace:
   0: <humility_core::dump::DumpCore as humility_core::core::Core>::read_8
   1: humility_core::hubris::HubrisArchive::registers
   2: humility_cmd_tasks::print_tasks
   3: humility_cmd_tasks::tasks
   4: humility_cmd::attach
   5: humility::cmd::subcommand
   6: humility::main
   7: std::sys::backtrace::__rust_begin_short_backtrace
   8: std::rt::lang_start::{{closure}}
   9: std::rt::lang_start_internal
  10: main
  11: __libc_start_call_main
  12: __libc_start_main_impl
  13: _start
   guessing at stack trace using saved frame pointer
   |
   +--->  0x24002048 0x080564de core::fmt::write
          0x240020a0 0x080564de core::fmt::write
          0x240020d8 0x08056b24 rust_begin_unwind
          0x240020d8 0x08055d12 core::fmt::Formatter::pad_integral::write_prefix

This output is kinda goofy, since there are two stack traces printed out, with different formatting.

While an astute reader can pretty easily determine that one of these looks like a stack trace in Humility rather than Hubris, it's still pretty weird that there are two stacks displayed, which is potentially confusing. We should probably not format the anyhow::Error with the format specifier that includes a backtrace in this case, since it's not really an internal error we'd need the backtrace to debug, and is instead an error regarding the dump we tried to read.

Reproduce the behavior with humility ... tasks <TASK> --stack and with --stack --guess, then trace the tasks command's handling of the anyhow error. Compare the two displayed traces; done means the dump error remains understandable without producing a second, confusing Humility backtrace alongside the Hubris stack trace.