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

erp5-data-notebook bt5: Refactor testExecuteJupyter to new JupyterCompile where we are letting errors fails loudly in erp5

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: Check user permission for at entry point for Base_executeJupyter python script so that non-developer user cannot execute python code through script

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

erp5_data_notebook: Add dict to convert string to Boolean in Base_executeJupyter python script for getting all the data notebooks

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.

So that we can have enough permissions in subobjects of solving Solver Process.

Otherwise test will fail because the user is not indexed yet

test: update causality state explicitly because normal users have no write to modify in solving state.

Because solve() is now unrestecred method.

This reverts commit ab9e6e69.

they are mostly 'Modify portal content' permission.

With ZODB Components, getBusinessTemplateList() only returns the test
bt5 (as given on the command line, such as BT_TITLE:testFoo) and later
it resolves dependencies.

So filtering bt5 to be updated should be done as late as possible...

Selection.__call__() calls getParams() and as getParams() can be called
directly from many places (such as SelectionTool.getSelectionParamsFor()),
it makes more sense to have it here.

1. On Tab1, from PurchaseSupply_view, click on 'Purchase Supply Lines':
   Base_viewListMode??proxy_form_id=PurchaseSupply_view&proxy_field_id=listbox

   This Python Script initialise 'list_mode_proxy_selection' with the
   above 2 GET parameters and then displays PurchaseSupply_view.listbox
   indirectly but current Form is Base_viewListModeRenderer.

2. On Tab2, from SaleSupply_view, click on 'Sale Supply Lines':
   Base_viewListMode?proxy_form_id=SaleSupply_view&proxy_field_id=listbox

   This Python Script initialise 'list_mode_proxy_selection' with the
   above 2 GET parameters and then displays SaleSupply_view.listbox
   indirectly but current Form is Base_viewListModeRenderer.

3. On Tab1, filter Purchase Supply Lines.

   As proxy_form_id and proxy_field_id are not given, then
   Base_viewListModeRender fallbacks on 'list_mode_proxy_selection'
   values to find out the Form ID to be called and wrongly display
   SaleSupply_view.listbox (2.).