erp5_data_notebook: moves variables and setup storage from ActiveProcess to `notebook_context` property

Notebook's variables and setup were being stored in an ActiveProcess, which is
not needed anymore, because now everything related to user context can be
safely stored in the ZODB.
They are stored in a `notebook_context` property of the Data Notebook
itself. Code and tests were updated properly. The old `process` property was removed.

All the references to *_variable_dict were renamed to  *_notebook_context, documentation
and tests were updated. Related objects like scripts and external methods were renamed
too.

To store objects in the `notebook_context` property we do 2 different tests: the first
to check if the object can be serialized by `ZODB.serialize.ObjectWriter`. If the first
test fails we test if the object can be serialized by cPickle. For the second test we
need to dump & load the object to be completely sure that it can be correctly loaded
later.

The function called by the Base_runJupyterCode external method was renamed from
Base_compileJupyterCode to Base_runJupyterCode be more consistent and avoid confusion.

All errors while running setup functions and now properly propagated to the user
interface in Jupyter and code execution is aborted.

- An environment object was implemented to help us deal with the multiprocess
architecture of ERP5 and objects that cannot be easily stored in the ZODB.
It stores definition of functions, classes and variables as string. The implementation
uses a dumb Environment class to allow users to make `define` and `undefine` calls,
which are captured and processed by an AST transformer before code execution.

- Along with the environment object, an automatic "import fixer" was created. It does
not allow users to import modules as they normally would, because this may cause
collateral effects on other users' code. A good example is the plot settings in the
matplotlib module. It will fix normal imports, make them use the environment object
mentione earlier automatically and warn the user about it.

A few bugs were fixed with this implementation, for example:

- https://nexedi.erp5.net/bug_module/20160318-7098DD, which reports an inconsistency
on portal catalog queries between Jupyter and Python (Script) objects. Probably an
issue with user context storage in ActiveProcess

- https://nexedi.erp5.net/bug_module/20160330-13AA193, which reports an error related
to acquisition when trying to plot images, which happened in other situations, although
this is not officially reported in Nexedi's ERP5. This probably also was happening because
of old user context storage.

This is the proper way to refer to the URL on which ERP5 is being served.

Jupyter now uses portal_caches instead of portal_memcached to store the
temporary PivotTableJs iframe that will be served to the frontend. This provides
another level of abstraction to how the iframe storage will work.

pivottablejs is a very useful pivot table implementation in Javascript that
alllows the user to create his own tables and charts. And also they had examples
of integration with Pandas.DataFrame objects and Jupyter. So this is highly
based on that.

**ATTENTION**: this is an experimental integration and does not follow the ERP5
Javascript standards. It will be refactored in the future to use RenderJS and
JIO.

The integration generates an HTML page template which starts the pivot table and
have a placeholder for the data, that will be later replaced with a Data Frame
data as CSV. After this replacement the page is stored in the memcached server
and then served from there, through a Script (Python) object, inside an HTML
iframe. The iframe is necessary because a lot of Javascript libraries that are
not included in the Jupyter web page are loaded.

A web page with id "PivotTableJs_getMovementHistoryList" was created to demo
how pivottablejs can be integrated within ERP5, either using AJAX or not.

In the process of this integration a simple external method to render
iPython's display classes (Images, Video, Youtube, IFrame, etc) was created. It
will be refactored and polished along with the kernel itself in the future.

@kirr, @Tyagov and @tatuya, please review.

Now the ERP5 Jupyter kernel automatically renders errors that happens in the
user-side code. Errors are captured during the AST tree creation (to be able to
detect syntax errors) and at execution time. The current transaction is
automatically aborted on error detection.

/reviewed-on nexedi/erp5!85

The external method Base_displayImage displays images of two kind: plot and OFS image
saved in erp5. We had earlier checks for erp5 images but no check to for matplotlib
plot images.

erp5_data_notebook bt5: Rename Base_savePlot to Base_saveImage and add kwargs in parameters for the external function

erp5_data_notebook bt5: Close plot object and after every call to Base_dispalyImage with matplotlib object

erp5_dat_notebook bt5: Add External method base_savePlot and use Image module as context while creating new Image Object in base_savePlot

erp5_dat_notebook bt5: Add Base_savePlot to JupyterCompile extension which would help creating an ERP5 Image object from matplotlib plots

erp5_data_notebook bt5: Rename Base_displayMatplotlibImage to Base_displayImage so as to make it sound more generic

mime_type for results for executed jupyter_code from JupyterCompile extension
has also been defined on the server side itself.

This would help server to have more command over what Content-Type  would be
displayed to jupyter frontend.

erp5_data_notebook bt5: Use dictionary to save module imports instead of saving it as list of strings.

Using dictinary its easier to update modules frequently.

For example, executing code:

'''
import numpy as np
import numpy
'''

would result as :
local_variable_dict['imports'] = {'numpy': 'numpy', 'np': 'numpy'}
which is what we expect to be saved in globals() also.

Problem: Module objects are not picklable, thus, trying them to save in
local_variable_dict which is further saved in ZODB via ActiveResult object
of CMFActivity was giving error. So, its better to save the module objects
as code_strings in local_variable_dict.

As for now, for example:
local_variable_dict = {'imports': ['import numpy as np', 'import matplotlib as mpl'],
			 'variables': {'a':1, 'b:2'}}
for jupyter_code = """
import numpy as np
import matplotlib as mlp
a= 1; b=2; print a+b
"""

erp5_data_notebook bt5: Use interactivity/mode and finally execute all code using exec to get rid of try:except

erp5-data-notebook bt5: Remove exception catching from Base_runJupyter external function and let the errors be raised loudly

erp5_data_notebook bt5: Add transaction abort and fail loudly in case of error in transaction script

erp5_data_notebook: Refactor jupyter_compile to only return the local variables which are added after code execution

erp5_data_notebook bt5: Updated extension JupyterCompile to use globals variable while running exec command

This BT is used to interact ERP5 with Jupyter and execute the python code.
1. External method `Base_executeJupyter` to interact between code from Jupyter and ERP5 backend.
2. Module - Data Notebooks
3. Unittest `JupyterCompile` to test external method and extensions.