Fixes #2305.

The reason this is happening is:

• When we hash a function, we're saving its co_cellvars and co_freevars in a table, and later looking them up when we resolve references.
• List comprehensions are their own code objects, nested inside the function's co_consts, with their own co_cellvars and co_freevars not listed in the outer function.
• We're only saving the outermost function's co_cellvars and co_freevars, so when we try to resolve references found inside the listcomp, it can't find them in our table, and crashes.

What we need to do is save all references as we recursively traverse our "tree" of nested code objects. In pseudocode, it looks something like this:

def hash_code_object(code_object):
    push_vars(code_object)

    hash.update(...)
    for child in code_object.nested_objects:
        hash_code_object(child)

    pop_vars()  # pop all the vars we pushed at the beginning, restoring old values

For example, this code

@st.cache()
def create_raw_data():
    production = [
        [outer + inner for inner in range(3)]
        for outer in range(5)
    ]
    return production

would produce (roughly) the following object hierarchy:

create_raw_data (vars: nothing)
└─ outer list comprehension (line 3) (vars: `outer`)
   └─ inner list comprehension (line 4) (vars: `inner`)

So if we're hashing create_raw_data, our cell table state would look like this over time.

• Start hashing create_raw_data: {}
• Start hashing outer listcomp: {'outer': ...}
• Start hashing inner listcomp: {'outer': ..., 'inner': ...}
• Finish hashing inner listcomp: {'outer': ...}
• Finish hashing outer listcomp: {}
• Finish hashing create_raw_data: {}

I basically replaced Context.cells, which was previously a simple dict, with a custom class that achieves this. Also, I added a test.

(Note: I recommend reading the diff in split view, it's a lot more readable than unified.)