rust-needsdrop checkpoint: plausible struct fragments.

Since I'm likely to remove this comment in a future rebase but want to
record it somewhere, here goes:

    // A digression on needs-drop design.
    //
    // Lets assume we had a pre-existing drop obligation ND = { s.a, s2 }, where:
    // ```
    // struct S { a: A, b: B, c: C }
    // struct A { i: I, j: J, k: K }
    // struct J { x: X, y: Y, z: Z }
    // ```
    // and `s : S` (and `s2 : S` as well).
    //
    // Moving `s.a.j.x` implies that:
    // * We no longer have a drop-obligation for s.a in its entirety: ND' := ND \ { s.a }
    // * We now do have drop-obligations for the portions of `s.a` that were not moved:
    //   ND' := ND + { s.a.i, s.a.k }
    // * Likewise, we also have drop-obligations for the portions of `s.a.j` that were
    //   not moved:
    //   ND' := ND + { s.a.j.y, s.a.j.z }
    //
    // Altogether, the above modifications accumulate to:
    // ND' := ND \ { s.a } + { s.a.i, s.a.j.y, s.a.j.z, s.a.k }
    //
    // To simplify constructions like the above let us define taking the derivative
    // of a path P with respect to an appropriate subpath suffix S: d/d{S}(P)
    //
    // So for example, d/d{.j.x}(s.a) := { s.a.i, s.a.j.y, s.a.j.z, s.a.k }
    //
    // TODO: Write definition of d/d{S}(P), presumably by induction on suffix S.
    //
    // For d/d{.j.x}(s.a), S = .j.x and P = s.a:
    //
    // 1. P_0 = s.a      : remove obligation s.a, if present
    //
    // 2. P_1 = s.a.j    : assert obligation s.a.j not present; add
    //                     all needs-drop fields of s.a, then remove s.a.j.
    // 3. P_2 = s.a.j.x  : assert obligation s.a.j.x not present; add
    //                     all needs-drop fields of s.a.j, then remove s.a.j.x.
    //
    // Big Question: Under the kill/gen paradigm, how do I ensure that
    // I only add the bits associated with d/d{.j.x}(s.a) and not the
    // bits associated with d/d{.a.j.x}(s) ?  I.e. the explanation
    // above makes assumptions about computations I will be able to do
    // as part the transfer function, but I need to encode those
    // computations as gen+kill bits.
    //
    // ==> one way to resolve this problem while remaining under the
    //     gen/kill paradigm is to carry-on with a suggestion I made
    //     to Niko a while back, namely to treat the path `s` as a
    //     shorthand for
    //
    //      `{ s.a.i, s.a.j.x, s.a.j.y, s.a.j.z, s.a.k, s.b, s.c }`,
    //
    //     and likewise `s.a` as as shorthand for
    //
    //      `{ s.a.i, s.a.j.x, s.a.j.y, s.a.j.z, s.a.k }`
    //
    //     That is, put these paths through a normalization process that
    //     unrolls them to their leaves (or at least, their leaves with
    //     respect to a given piece of code.
    //
    //     I might even be able to implement this independently of
    //     the other dataflow analyses, since happenstance led me
    //     to make the needs-drop analysis separate from the
    //     loans/moves/assigns analyses.
    //
    // UPDATE: The above is in fact the strategy that Felix went with.
    // The above comment should be revised/shortened to a succinct
    // summary.