Fix panics in the C API related to trap frames (#4196)

The `wasmtime-cpp` test suite uncovered an issue where asking for the
frames of a trap would fail immediately after the trap was created. In
addition to fixing this issue I've also updated the documentation of
`Trap::frames` to indicate when it returns `None`.

crates/wasmtime/src/config.rs

@@ -288,7 +288,6 @@ impl Config {
     ///
     /// When disabled, wasm backtrace details are ignored, and [`crate::Trap::trace()`]
     /// will always return `None`.
-
     pub fn wasm_backtrace(&mut self, enable: bool) -> &mut Self {
         self.wasm_backtrace = enable;
         #[cfg(compiler)]

crates/wasmtime/src/trap.rs

@@ -295,6 +295,14 @@ impl Trap {
 
     /// Returns a list of function frames in WebAssembly code that led to this
     /// trap happening.
+    ///
+    /// This function return an `Option` of a list of frames to indicate that
+    /// wasm frames are not always available. Frames will never be available if
+    /// backtraces are disabled via
+    /// [`Config::wasm_backtrace`](crate::Config::wasm_backtrace). Frames will
+    /// also not be available for freshly-created traps. WebAssembly frames are
+    /// currently only captured when the trap reaches wasm itself to get raised
+    /// across a wasm boundary.
     pub fn trace(&self) -> Option<&[FrameInfo]> {
         self.inner
             .backtrace