peepmatic: Be generic over the operator type

This lets us avoid the cost of `cranelift_codegen::ir::Opcode` to
`peepmatic_runtime::Operator` conversion overhead, and paves the way for
allowing Peepmatic to support non-clif optimizations (e.g. vcode optimizations).

Rather than defining our own `peepmatic::Operator` type like we used to, now the
whole `peepmatic` crate is effectively generic over a `TOperator` type
parameter. For the Cranelift integration, we use `cranelift_codegen::ir::Opcode`
as the concrete type for our `TOperator` type parameter. For testing, we also
define a `TestOperator` type, so that we can test Peepmatic code without
building all of Cranelift, and we can keep them somewhat isolated from each
other.

The methods that `peepmatic::Operator` had are now translated into trait bounds
on the `TOperator` type. These traits need to be shared between all of
`peepmatic`, `peepmatic-runtime`, and `cranelift-codegen`'s Peepmatic
integration. Therefore, these new traits live in a new crate:
`peepmatic-traits`. This crate acts as a header file of sorts for shared
trait/type/macro definitions.

Additionally, the `peepmatic-runtime` crate no longer depends on the
`peepmatic-macro` procedural macro crate, which should lead to faster build
times for Cranelift when it is using pre-built peephole optimizers.

cranelift/peepmatic/crates/macro/src/lib.rs

@@ -11,14 +11,8 @@ use syn::{parse_macro_input, Ident, Result};
 
 mod child_nodes;
 mod into_dyn_ast_ref;
-mod operator;
 mod span;
 
-#[proc_macro_derive(PeepmaticOperator, attributes(peepmatic))]
-pub fn operator(input: TokenStream) -> TokenStream {
-    operator::derive_operator(input)
-}
-
 #[proc_macro_derive(Ast, attributes(peepmatic))]
 pub fn derive_ast(input: TokenStream) -> TokenStream {
     let input = parse_macro_input!(input as DeriveInput);