Size closures correctly.

Summary:
pympler does not look into func_closure correctly, causing it to miss
memory that may be owned by a closure. Here is a simple repro case:

    import pympler.asizeof as sz
    cp = lambda x: lambda: x
    fn = cp([1] * 40000)
    cell = fn.func_closure[0]
    sz.asizeof(cell)   # returns 0, should return 160072 (on 32-bit machine)

This causes sz.asizeof(fn, code=True) to be something like 560 rather
than 160000-ish.

The problem is that pympler does not have special-casing for the
'cell' type, which is where python encodes data that is held by a
closure.

This change fixes this, at least in my tests.  There is an aspect of
cargo-culting here, so I'm not sure the fix is totally correct, but it
works on the above test case, at least.

Test Plan:
Ran the above code snippet (including the asizeof(fn, code=True)) and
verified the sizes reported were above 160000.

Reviewers: chris

Differential Revision: http://phabricator.khanacademy.org/D6981
Size closures correctly.

Summary:
pympler does not look into func_closure correctly, causing it to miss
memory that may be owned by a closure. Here is a simple repro case:

    import pympler.asizeof as sz
    cp = lambda x: lambda: x
    fn = cp([1] * 40000)
    cell = fn.func_closure[0]
    sz.asizeof(cell)   # returns 0, should return 160072 (on 32-bit machine)

This causes sz.asizeof(fn, code=True) to be something like 560 rather
than 160000-ish.

The problem is that pympler does not have special-casing for the
'cell' type, which is where python encodes data that is held by a
closure.

This change fixes this, at least in my tests.  There is an aspect of
cargo-culting here, so I'm not sure the fix is totally correct, but it
works on the above test case, at least.

Test Plan:
Ran the above code snippet (including the asizeof(fn, code=True)) and
verified the sizes reported were above 160000.

Reviewers: chris

Reviewed By: chris

Differential Revision: http://phabricator.khanacademy.org/D6981