FIX added checking into sys.modules before trying to import base_globals

[pierreglaser]

during unpickling, in order to recreate the previous environnement an object lived in,
the module under the base_globals name is re-imported. However, it
is not always possible, especially if base_globals pointed to a
temporary or locally defined module. This PR introduces a fix that
checks if the module still exists during unpickling.

[pierreglaser]

More precisely:

base_globals contains the name of the module the pickled object lived in.

Initially, in the case of interactively defined functions, #187 allowed the
creation the global variables of the pickled function that do not exist when unpickling,
but not overriding the ones that already exist in __main__. It was done by doing

base_globals = vars(sys.modules[base_globals])

and then updating func.__globals_.

(in this case base_globals is __main__)

Extending it to other modules can cause errors for cases when the module does
not exist in sys.modules.
Namely:

1. the instanciation of a new namedtuple subclass (the __new__ method is created
   by it is done calling exec with hardcoded globals argument,
   including the module name __name__ that is in this case

f'namedtuple_{typename}'

2. using dynamic modules or faulty modules that are not referenced in
   sys.modules
3. using local modules, that can be imported because '' is in sys.path

For 1 and 2, I am not sure there is a need to handle gloabals updating,
as it looks to me that these modules are aimed to be created on the fly, saved, and then thrown
away or untouched until they get reloaded

For 3, the fix in this PR checks if base_globals exists in sys.modules during
unpickling.

[ogrisel]

Fixed by cloudpipe#198.