Remove some dependencies

[bjorn3]

• Remove the thiserror dependency from cranelift-codegen and cranelift-module and use a cleaned up version of it's derives expansion instead.
  This improves compilation time of cg_clif by 6s. For users of cranelift that don't already disable optimizations for syn and other dependencies of the thiserror proc macro, the release mode compilation time wins will be even larger.
• Remove some unnecessary dependencies as found by cargo-udeps.

[pchickey]

I approve these changes in cranelift-module. I'm not a maintainer of cranelift-codegen so I will defer overall approval to someone else - @cfallin maybe?

[cfallin]

It's somewhat surprising to me that changes in error-printing code would give such a large speedup in compile times. It's always welcome, of course, when speedups come -- but @bjorn3, do you have any sense of why this happens? I ask because it could be a symptom of something weirder going on behind the scenes -- for example, are we throwing a bunch of errors and doing work to capture backtraces but then silencing them somehow?

All other things being equal, the auto-derived error handling is kind of nice, but I won't fight too hard for it if we win by doing something lighter-weight.

[pchickey]

I believe, because thiserror is a proc macro that depends on the usual stack of syn and friends, that compiling those dependencies is the tentpole in embeddings which otherwise don't use proc macros. So, we don't see this in wasmtime or other big applications where we use that family of crates in several contexts, but I imagine that cg_clif is very careful about deps.

[cfallin]

Ah -- to clarify, @bjorn3, you mean the compile time of cg_clif, not the time that cg_clif takes to compile code?

(I was assuming the latter, and thus was quite confused about the impact of error-path code on the happy path!)

[bjorn3]

Ah -- to clarify, @bjorn3, you mean the compile time of cg_clif, not the time that cg_clif takes to compile code?

Correct, I mean the time it takes to compile cg_clif itself. Sorry for the confusion.

but I imagine that cg_clif is very careful about deps.

Indeed. I try to avoid dependencies where possible and even use dependencies from the rustc-dev rustup component instead of crates.io where possible.

[cfallin]

Looks good -- I definitely am in agreement with the idea that our core libraries should try not to pull too much in. (IIRC this has been stated as a goal at one time or another but the tendency is always to drift in the other direction...) Happy to merge once the conflicts are resolved.

[pchickey]

Would you mind leaving a comment above the Display & Error impls that these are written by hand to avoid pulling in the thiserror dep? That may help anyone who sees them and gets the clever idea that they can be replaced by a macro.

[bjorn3]

Done

[bjorn3]

Rebased