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.

I just [commented about this](https://github.com/rust-lang/rfcs/pull/210#issuecomment-53520183), but to clarify, I don't see the point in this rule. The following seem roughly equivalent to me:

```rust
let val = some_non_copy_value();
if cond() {
    foo(val); // consumes val
} else {
    bar(&val); // doesn't consume val
}
// at this point val is implicitly dropped if the else branch was taken.
```

vs

```rust
let val = some_non_copy_value();
match val {
    Foo(x) => { // by-value capture
        foo(x);
    }
    Bar(ref x) => { // by-reference capture
        bar(x);
    }
}
```

In the `if` case, the user can explicitly add the `drop(val)` call at the end of the `else` branch. In the `match` case, the user cannot do this (until we get non-lexical borrows). But the fact that the user cannot insert this does not mean the *compiler* cannot do so for us.

The only issue I see with letting the compiler do this is that leaves no way for the user to quiet a `NoisyDrop` warning. But I think that's a reasonable limitation to live with until such time as we get non-lexical borrows. Certainly better than ruling out a `match` that has no safety issues.

---

Importantly, I think the important thing here is control flow. In both cases, control flow branches, and merges back together, and the drop obligations need to be merged. The implicit drops that fix this in the `if` case work just as well in the `match` case. The only thing the compiler has to be careful about is making sure the implicit drop is run after the cleanup of the match arm scope; at that point, the borrow is guaranteed to not be used anymore, so it's safe to drop the value.