Earlier, migrateSQLCatalogToERP5Catalog was used only for creating a new ERP5Catalog
and then migrating the objects and properties from sql catalog to this new ERP5 catalog.
This sometimes led to the problem while we install new business templates which do have
Catalog methods. So, the soluton to this is to update this migration function to do the
updation part also. So now we can call this function everytime after we install a BT5
and it'll create/update ERP5Catalog as per needed.

Please note that this hack is not an efficient way to carry this process. Instead the
better option imho(Ayush) is to change completely the BT5 methods structure of handling
Catalog methods which at present time have hardcoded sql_catalog name attached to their
paths.

The reason is we need the new ERP5Catalog object to have all the
methods and properties which is possible only if SQLCatalog.Catalog object
has been instantiated with the methods and properties. So we create
this object while running migration from SQLCatalog to ERP5Catalog and
that is being done while running setUp for ERP5Site.

We need objects as well as properties to be setup because objects inside Catalogs
are basically zsql_methods which is what is needed when we use the properties.

For example: making call to `new_erp5_catalog.sql_clear_catalog` would return
a tuple of zsql methods which are basically catalog objects.
Right now, we are copying everything from SQLCatalog to the new ERP5Catalog without
checking for any conflicts(which is why there might be some overwrite).
This is why its recommended to call the migration function only furing ERP5Site setup.
TODO: This overwriting would be fixed later on so to make the migration function
a bit more generic and use it anytime-anywhere.

erp5_catalog: Inherit from Catalog class from Products.ZSQLCatalog.SQLCatalog instead of copy-pasting the whole code again.

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.