This lint checks for statements similar to `let _ = foo`, where `foo` is
a type that implements `Drop`. These types of let statements cause the
expression in them to be dropped immediately, instead of at the end of
the scope. Such behavior can be surprizing, especially if you are
relying on the value to be dropped at the end of the scope. Instead, the
binding should be an underscore prefixed name (like `_unused`) or the
value should explicitly be passed to `std::mem::drop()` if the value
really should be dropped immediately.

Similar to `let_underscore_drop`, this lint checks for statements similar
to `let _ = foo`, where `foo` is a lock guard. These types of let
statements are especially problematic because the lock gets released
immediately, instead of at the end of the scope. This behavior is almost
always the wrong thing.

Similar to `let_underscore_drop`, this lint checks for statements similar
to `let _ = foo`, where `foo` is an expression marked `must_use`.

This was done to pass `tidy`.

These lints are very noisy and are allow-by-default in clippy anyways.
Hence, setting them to allow-by-default here makes more sense than
warning constantly on these cases.

This commit uses `span_suggestion_verbose` to add what specific code
changes can be done as suggested by the lint--in this case, either binding
the expression to an unused variable or using `std::mem::drop` to drop
the value explicitly.

Clippy sets this lint to Deny by default, and it having the lint be Deny
is useful for when we test the lint against a Crater run.

If the type has a trivial Drop implementation, then it is probably irrelevant
that the type was dropped immediately, since nothing important
happens on drop. Hence, we can bail out early instead of doing some
expensive checks.

…lock`

Using diagnostic items avoids having to update the paths if the guard
types ever get moved around for some reason. Additionally, it also greatly
simplifies the `is_sync_lock` check.

We don't actually care about running these programs, only checking the
warnings they generate.

The `let_underscore_must_use` lint was really only added because clippy
included it, but it doesn't actually seem very useful.

I forgot to add the diagnostic to the actual types in `std` earlier.

The "consider explicitly droping" can now suggest a machine applicable
suggestion now.

This is done so that we can check the noisiness of this lint in a Crater
run. Note that when I built the compiler, I actually encountered lots of
places where this lint will trigger and fail compilation, so I had to
also set `RUSTFLAGS_NOT_BOOSTRAP` to `-A let_underscore_drop` when
compiling to prevent that.

This lint is way way too noisy to have it be `Deny` by default.

Currently, the let_underscore_lock lint simply tells what is wrong, but
not why it is wrong. We fix this by using a `MultiSpan` to explain
specifically that doing `let _ = ` immediately drops the lock guard
because it does not assign the lock guard to a binding.

I'm not really sure why this is nessecary to do, but the checks on the
PR do not seem to work if do not do this.