Avoid non-exhaustive matches on Expression.

Non-exhaustive matches on `Expression` make it harder to review changes that add
new enum variants, because the compiler can't tell you that you've missed a
case.

Although I believe Clippy is able to do so, I don't think we should make a
blanket rule of forbidding wildcard match arms against `Expression`. There are a
few matches that are only concerned with a handful of variants, or a single
variant. For example, variant, naga::front::spv::Parser::next_block is only
concerned with whether an expression is a constant or not. In principle, these
sites should also be checked when adding a new variant, but it seems too
burdensome to require them to list all the `Expression` variants they don't care
about. The principle should be applied only to matches that are already handling
most variants.

At the moment, there is only one such match on `Expression` in the code base,
and it's only missing a few variants, so this is quick to fix.

src/back/spv/writer.rs

@@ -1993,8 +1993,10 @@ impl Writer {
                 });
                 id
             }
-            ref other => {
-                log::error!("unimplemented {:?}", other);
+            crate::Expression::ImageQuery { .. } |
+            crate::Expression::Relational { .. } |
+            crate::Expression::ArrayLength(_) => {
+                log::error!("unimplemented {:?}", ir_function.expressions[expr_handle]);
                 return Err(Error::FeatureNotImplemented("expression"));
             }
         };