This dump was made with a connection string on 127.0.0.1, which must be
causing erros in logs:

    2020-04-09 09:35:02.699 CRITICAL ERP5Site Automatic migration of core tools failed
    Traceback (most recent call last):
      File "erp5/product/ERP5Type/dynamic/portal_type_class.py", line 456, in synchronizeDynamicModules
        portal.portal_activities.initialize()
      File "erp5/product/CMFActivity/ActivityTool.py", line 694, in initialize
        activity.initialize(self, clear=False)
      File "erp5/product/CMFActivity/Activity/SQLBase.py", line 173, in initialize
        db = activity_tool.getSQLConnection()
      File "erp5/product/CMFActivity/ActivityTool.py", line 674, in getSQLConnection
        return self.aq_inner.aq_parent.cmf_activity_sql_connection()
      File "eggs/Products.ZSQLMethods-2.13.5-py2.7.egg/Shared/DC/ZRDB/Connection.py", line 194, in __call__
        self.connect(s)
      File "erp5/product/ERP5Type/tests/ERP5TypeTestCase.py", line 926, in connect
        return original_ZMySQLDA_connect(self, *args, **kw)
      File "erp5/product/ZMySQLDA/DA.py", line 156, in connect
        connection = pool[self._p_jar] = DB(s)
      File "erp5/product/ZMySQLDA/db.py", line 229, in __init__
        self._forceReconnection()
      File "erp5/product/ZMySQLDA/db.py", line 316, in _forceReconnection
        self.db = MySQLdb.connect(**self._kw_args)
      File "develop-eggs/mysqlclient-1.3.12-py2.7-linux-x86_64.egg/MySQLdb/__init__.py", line 86, in Connect
        return Connection(*args, **kwargs)
      File "develop-eggs/mysqlclient-1.3.12-py2.7-linux-x86_64.egg/MySQLdb/connections.py", line 204, in __init__
        super(Connection, self).__init__(*args, **kwargs2)
    OperationalError: (2002, "Can't connect to MySQL server on '127.0.0.1' (115)")

We first thought about using a connection string that would work on test
node, something like:

    erp5_test_0@erp5-catalog-0:2099 testuser_0 testpassword0

but since testnodes share mysql connections, this would be wrong if for
exemple this testnode was affected with erp5_test_1 and another test
node was already running with erp5_test0.

Instead, we use another approach, the reference Data.fs uses a marker
string as connection string and before running test, the testnode
rewrite the Data.fs to replace the marker string by the actual
connection string. Because ZODB file storage is simple, we can just
replace string in the database file, as long as the replacement string
have the same length as the replaced string.

Dump was produced this way:

    runUnitTest --save --erp5_sql_connection_string 'erp5_test_0@erp5-catalog-0:2099               testuser_0 testpassword0' --portal_id=erp5 testUpgradeInstanceWithOldDataFs
    python3 rewrite_data_fs.py

This test checks that an old instance can be upgraded successfully through
upgrader to the current ERP5 version.

Data.fs and dump.sql were created by the following command with erp5.git at
d8961c51 (just before the first filesystem Product to be migrated to ZODB
Components (ERP5ShortMessage)):
  runUnitTest --save testUpgradeInstanceWithOldDataFs

/reviewed-on nexedi/erp5-bin!4

Also update the dependency list

We have to initialize pyodide first

Prepare to initialize pyodide when executing JS code block

Load and initialize pyodide python wasm module
Display the output of Python code

Cache type set to must_reinvlidate_http_cache
Set the content type to application/wasm for the *data files

The previous files were built on normal Linux
The updated files were built on SlapOS

Ayush seems to submitted everything he got by compiling Pyodide.
Some of them are not needed for our erp5_notebook project. Remove it.

Move erp5_notebook bt from erp5 repository to erp5-bin repo