Carefully consider: should we be deny()ing any built-in warnings?

Inspired by #950 (closed)

We currently use deny on the following built-in compiler warnings:

#![deny(missing_docs)]
#![deny(unreachable_pub)]

These are both warnings that we never want to ship with, but deny()ing them creates a risk. If any future version of rustc extends these warnings so that they trigger in more cases of code, then all current versions of arti would fail to compile with those versions of rustc.

Possible decisions:

1. We trust that rustc will never make missing_docs or unreachable_pub apply in more cases than it does today.
2. We declare that we don't care if future versions of rustc won't compile existing versions of arti.
3. We change these denys to warns, but add -D warnings or whatever the flag is to our CI build flags, and encourage people to do the same in their local development environments.
4. ... something else?

(Every other lint that we deny is from clippy; this issue doesn't apply to clippy warnings, since failing to pass future versions of clippy won't keep our code from compiling.)