Introduce and avoid dropck

Dropck was never formally introduced. As it was used a single time, I just
replace it by its full length name. I also introduce it on the first "drop
checker" reference for exhaustivity.

src/dropck.md

@@ -121,9 +121,9 @@ Interestingly, only generic types need to worry about this. If they aren't
 generic, then the only lifetimes they can harbor are `'static`, which will truly
 live _forever_. This is why this problem is referred to as _sound generic drop_.
 Sound generic drop is enforced by the _drop checker_. As of this writing, some
-of the finer details of how the drop checker validates types is totally up in
-the air. However The Big Rule is the subtlety that we have focused on this whole
-section:
+of the finer details of how the drop checker (also called dropck) validates
+types is totally up in the air. However The Big Rule is the subtlety that we
+have focused on this whole section:
 
 **For a generic type to soundly implement drop, its generics arguments must
 strictly outlive it.**

src/phantom-data.md

@@ -64,9 +64,9 @@ about Vec dropping any T's in its destructor for determining drop check
 soundness. This will in turn allow people to create unsoundness using
 Vec's destructor.
 
-In order to tell dropck that we *do* own values of type T, and therefore may
-drop some T's when *we* drop, we must add an extra `PhantomData` saying exactly
-that:
+In order to tell the drop checker that we *do* own values of type T, and
+therefore may drop some T's when *we* drop, we must add an extra `PhantomData`
+saying exactly that:
 
 ```rust
 use std::marker;