Static drop semantics

Switch to static drop semantics to remove the drop-flag and memory zeroing.

[rendered view](https://github.com/pnkfelix/rfcs/blob/fsk-nzdrop-rfc/active/0000-remove-drop-flag-and-zeroing.md#summary)

# Summary

Three step plan:

 1. Revise language semantics for drop so that all branches move or drop the same pieces of state ("drop obligations").  To satisfy this constraint, the compiler has freedom to move the drop code for some state to earlier points in the control flow ("early drops").

 2. Add lints to inform the programmer of situations when this new drop-semantics could cause side-effects of RAII-style code (e.g. releasing locks, flushing buffers) to occur sooner than expected.

    Types that have side-effectful drop implement a marker trait, `NoisyDrop`, that drives a warn-by-default lint; another marker trait, `QuietDrop`, allows types to opt opt.  An allow-by-default lint provides a way for programmers to request notification of all auto-inserted early-drops.

 3. Remove the dynamic tracking of whether a value has been dropped or not; in particular, (a) remove implicit addition of a drop-flag by `Drop` impl, and (b) remove implicit zeroing of the memory that occurs when values are dropped.

This is the original approach I thought we'd take to remove drop flags (it's certainly the approach discussed in IRC a long time ago).

Personally, I think it's the best approach, because a) it should preserve the drop semantics of all existing code, b) it completely avoids all the `NoisyDrop`/`QuietDrop` stuff, and c) it preserves user expectation that live values are dropped at the end of the scope.