Bring back Module::deserialize (#2858)

* Bring back `Module::deserialize`

I thought I was being clever suggesting that `Module::deserialize` was
removed from #2791 by funneling all module constructors into
`Module::new`. As our studious fuzzers have found, though, this means
that `Module::new` is not safe currently to pass arbitrary user-defined
input into. Now one might pretty reasonable expect to be able to do
that, however, being a WebAssembly engine and all. This PR as a result
separates the `deserialize` part of `Module::new` back into
`Module::deserialize`.

This means that binary blobs created with `Module::serialize` and
`Engine::precompile_module` will need to be passed to
`Module::deserialize` to "rehydrate" them back into a `Module`. This
restores the property that it should be safe to pass arbitrary input to
`Module::new` since it's always expected to be a wasm module. This also
means that fuzzing will no longer attempt to fuzz `Module::deserialize`
which isn't something we want to do anyway.

* Fix an example

* Mark `Module::deserialize` as `unsafe`

examples/serialize.rs

@@ -29,9 +29,12 @@ fn deserialize(buffer: &[u8]) -> Result<()> {
     println!("Initializing...");
     let store = Store::default();
 
-    // Compile the wasm binary into an in-memory instance of a `Module`.
+    // Compile the wasm binary into an in-memory instance of a `Module`. Note
+    // that this is `unsafe` because it is our responsibility for guaranteeing
+    // that these bytes are valid precompiled module bytes. We know that from
+    // the structure of this example program.
     println!("Deserialize module...");
-    let module = Module::new(store.engine(), buffer)?;
+    let module = unsafe { Module::deserialize(store.engine(), buffer)? };
 
     // Here we handle the imports of the module, which in this case is our
     // `HelloCallback` type and its associated implementation of `Callback.