The script also changes the default_sql_catalog_id for the current portal_catalog

Use default_sql_catalog_id as the object from ERP5Catalog class instead
of using catalog from Products.ZSQLCatalog.SQLCatalog.Catalog class.
This is required in the step by step migration of catalog inside ERP5.

We try to move from using SQLCatalog to ERP5Catalog as the default Catlaog inside
ERP5. The major difference is use of Folder class as the base for Catalog from
Products.ERP5Type.Core

erp5_catalog: Use manage_options obejct from Folder class and initiate both ZCatalog and Folder in __init__

As this is a meta_type, I hope this naming is not breaking conventions of using plurals inside
ERP5. This renaming is required cause we are moving SQLCatalog to ERP5Catalog and we don't want
naming conflicts or confusions between CatalogTool(whose meta_type used to be ERP5 Catalog) and
ERP5Catalog class.

erp5_catalog: Rename Folder module from OFS to remove conflict between it and the Folder module from ERP5Type.Core

erp5_catalog: Move View label from top to middle in manage_options tuple as we want it to be the default one while developemnt

***Honor naming conventions***

External methods are used in cases where call is being made to the restrcited
functions from Products.ZSQLCatalog.Catalog class

To use some private functions from Catalog Class in restricted ERP5 environment,
we create extensions here and use external method to call them.

!WARNING!  : External methods in restricted env.(Debugging currently)

manage_schema is not needed in case of CatalogTool for now.

We are keeping the views for catalogs inside erp5_core portal_skin to
maintain consistency

Using CopyContainer to use functions from inherited class also and maintain
consistency between them.

inside ERP5.

This is the 1st step in moving ZSQLCatalog inside ERP5. Therefore,
we try to remove the dependencies on OFS one by one. Here. we change
this for Folder module and also reomved the monkeypatching of
getPath(which is being used in CopyContainer in CopySupport). The
reason for doing so is to imply using getPath from Base for CatalogTool
objects which was earlier directed to ZSQLCatalog as it use ZSQLCatalog
as one of its base class.

While trying to use module `Products.ERP5.Core.Folder` in ZSQLCatalog,
circular dependencies in Base caused error, so for testing we try to
defer the imports to local context where they are specifically needed.

p Please enter the commit message for your changes. Lines starting

erp5_catalog: Prefer using CopyContainer from OFS due to inconsistency between CatalogTool and CopyContainer in ERP5Type

The commit 7e84b4e8 did break the instance, this can be considered
as the revert.

getpath function in ZSQLCatalog takes an extra agrument which is
not needed while using getPath in Base.
This process can be counted as a step in the transition of Catalog
inside ERP5. Though ZSQLCatalog is also a part(read: content) of Catalog Tool,
its better to move it side by side with keeping in mind no failure in the
tests of ERP5.

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

The function reindexObject at CatalogTool has bee renamed to reindexCatalogTool
in the commit 3b760022 . For CMFCatalogAware to be compatibile to use in
CatalogTool, we need to renmae the patched reindexObject here also.