Once confident in dropck: remove `#[unsafe_destructor]` attribute

[pnkfelix]

Spawned off of #8861, this is the last step in RFC #769, Sound Generic Drop.

Basically, once we are relatively confident that:

• the Drop-Check rule is sound,
• the dropck code is at least a sound approximation of that rule, and
• we have audited APIs in libstd for destructor safety,

then we should remove the #[unsafe_destructor] attribute and all the uses of it.

[pnkfelix]

Nominating; we should decide whether we are going to do this for 1.0 beta, or if it can wait until the 1.0 release itself as a "polish issue." (or if it can wait even beyond that, i.e. to 1.x. But I am not advocating that position.)

(However, given that #21972 just landed today, it may be a good idea to let the code settle for a week before we actually make a decision about this. Its super easy to remove #[unsafe_destructor], as one can see from the two commits here, its just a matter of having the will to do it. :) )

[pnkfelix]

1.0 beta, P-high.

[SSheldon]

@pnkfelix, is this still slated for the 1.0 beta? unsafe_destructor is the last feature my library uses, and I'd love to be able to run it stable on the beta. (Some discussion in #8142 seems to indicate that's a blocker but won't be completed for the beta.)

[pnkfelix]

@SSheldon I'm going to try, but I don't know if I'll be able to do everything necessary to unfeature gate it by the beta. We will see, I'm reviewing the remaining tasks now.

[SSheldon]

@pnkfelix, thanks! For what it's worth, I was able to remove the unsafe_destructor feature in my library by moving some of the fields of my struct into a new, non-generic struct and implementing Drop on that instead of the generic struct: SSheldon/rust-objc@b2bd3e0. (For anyone else that runs into this, that could potentially be a workaround.)

[diwic]

If you can't unfeature gate the entire unsafe_destructor, would it be possible to only unfeature gate those Drop impls we're confident with? Like, the simple and obvious ones (for various values of "simple" and "obvious" :-) ). I suspect a majority of Drop impls would be simple and obvious.