Use filter attributes as property. Same as done for ERP5 SQL Methods.
This way maintains consistency between sub-objects of Catalog, i.e,
SQL Method and Python Script.

Contains views, property sheets,  portal types concerning migration of
portal_catalog, sql catalog and their subobjects to erp5 object.

Portal Types:
1. Catalog : ERP5 Catalog object (an ERP5 Folder), which earlier used to be OFS Folder.
	Actions:
		Update Catalog
		Clear Catalog
		Clear Reserved
		Export Properties

2. Catalog Tool: Portal Catalog where we can add and use multiple ERP5 catalogs.
	Actions:
		Hot ReindexAll

3. SQL Method: SQL methods with their views inside erp5.
	Actions:
		Run Method

Property Sheet:
1. Catalog
2. CatalogTool
3. SQLMethod
	Containing properties for the various portal_types/classes respectively.
4. CatalogFilter

Also, filter_dict for erp5_catalog would now not be a Persistent Mapping
object. The info inside filter_dict is being saved inside the SQL Method
objects as their properties.

Views:
1. Catalog (View)
2. CatalogTool(View, Properties, Filtered Items), Object Actions
3. SQLMethod (View, Filter)
4. Python Script (Filter)

Extras:

	- Dialog view for catalog before clear_catalog

	- Add typeBaseMethod(s) for PythonScript and SQLMethod portal types:
The methods <portal_type>_getRedirectParameterDictAfterAdd are required for these
portal_types, cause their __call__ methods are overridden, so after addition
of new objects for them, it was taking to the url concerning wherever __call__
methods directed them.
Now, we change them to redirect to 'abosulte_url+'/view'' which is basically
the homepage for these catalog methods.

	- Do not use default ERP5 Catalog to show properties:
Earlier, in tales for properties for any erp5 catalog, we showed
the values for the default_erp5_catalog. But keeping in mind that
we can have multiple catalogs at same time, the old approach
was wrong. Hence, we now display properties for the current catalog

	- Search fo Catalog_viewContentList and Catalog_viewFilterList

abcd

- This step is needed due to the use of BaseTool as Base class for CatalogTool
  due to which there were conflict between reindexObject from the Base and the one
  from the BaseTool.

	- Remove copy-pasting all code from CatalogTool, better to rely on inheritence
	- Remove unnecessary imports
	- Add argument id in __init__ class
	- Add functions _isBootstrapRequired and _bootstrap
	- Update BusinessTemplate installation according to changes made in ERP5Catalog and Tool
	- Explicilty add manage option tabs in Catalog Tool

- Update testCopySupport according to changes in portal_catalog

Its better to change the tests where they need to call getpath function of
portal_catalog to use portal_catalog.getpath instead of portal_catalog.getPath,
as we have overridden the 'getPath' function for CatalogTool class due to change
in inherited class.

Move from SQLCatalog to ERP5Catalog as the default Catalog inside ERP5.
The major difference is use of Products.ERP5Type.Core.Folder as Catalog
base class.

Significant changes:
	-Inherit from Catalog class from Products.ZSQLCatalog.SQLCatalog instead of copy-pasting the whole code again.
	-Add allowed_types for ERP5Catalog tool
	-Monkey patch some property setters and getters to maintain consistency
	-Update id and title for ERP5Catlog while class initialization
	-Set declarative securities and solve some inheritance conflicts
	-Add isRADContent for ERP5Catalog Class
 	-Solve inheritence conflict for _setPropValue function in ERP5Catalog class
	-Add SQL Method portal_type in allowed_types for ERP5Catalog class
	-Override getCatalogMethodIds cause it uses global variable in SQLCatalog.Catalog
	-Redefine security declarations
	-Add functions for object_actions of Catalog portal_type in ERP5Catalog object
	-Add filter_dict attribute for compatibilty

Also,
- Update BusinessTemplate installation with updated filter_dict
This removes the need to copy-patch or if-else on meta_type of catalog.
Use dynamic migration while installing the catalog method objects for
bt5.
- Update tests according to changes in portal_catalog
- Create FilterDict and Filter class which would be used to imitate the behaviour
of filter_dict for Catalog.

Create the SQLMethod class based on ZSQLMethods.SQL
class and XMLObject. Also, move attributes to
property in 'SQL Method' property sheets.

Also, we don't need to look for `transactionless` connection-id here, as we don't use them in
catalog methods.

And, update the files where we can use the new function.

This commit contains two main changes:
- Add worklist gadget to the homepage.
- Remove the child's `changeState` calls in homepage.
  This was done by using customized `form_list_sr`. Which can let the listbox
  has same appearance like `form_view` but use same argument passing mechanism
  as `form_list`.

/reviewed-on nexedi/erp5!415

[erp5_officejs] Add cachealldocs Storage to cache allDocs call results and then service get requests with them

Test passed :  

https://nexedijs.erp5.net/#/test_result_module/20170926-4163AF53

/reviewed-on nexedi/erp5!414

/reviewed-on nexedi/erp5!409

/cc @aurel 

/reviewed-on nexedi/erp5!411

To generate (and execute) SQL, use catalog tool.

/reviewed-on nexedi/erp5!408

This reverts commit 206fa603 (which was
itself a revert commit), re-applying the change now that surrounding
code is ready for it.

Ignored columns are produced when aliasing a column. For example,
aliasing "catalog.reference" as "reference".
Before this change, this would cause conditions on "reference" to be
rendered non-mapped, which can cause SQL execution issues when there is
more than one "reference" column available (catalog.reference and its
alias counting as only one), which is the case when
catalog-category-catalog joins happen.

Instead, render all columns which could be mapped, independently from
their "ignored" status.

Also, use a different local variable for table aliases than for column
aliases.
Also, use more "return" statements, and simplify conditional structure.

As per Jérome, who implemented the test, it was written to test the
current state rather than testing the desired outcome. And it makes
little sense to have (and test for) 100 being present in both debit and
credit columns ("normal" lines), and 0 to be present in the stat line.

Update test to check for a more consistent outcome.
Acked-by: Jérome Perrin <jerome@nexedi.com>

Explicitely state which values represent empty values. Coercing to boolean is not sufficient.

-  Remove field_json.value because that one is never send by ERP5 backend
-  Set comprehensive initial state and avoid sneaking state variables afterwards
-  Handle better NaNs which represent empty numerical value
-  Refactor for shorter and simpler code
-  Rename "percents" -> "percentage" according to coding style guidelines