erp5_catalog: Makes better sense to have bt5 in bootstrap as it'd be installed during ERP5Site setup

erp5_catalog: Ignore case for title property and update default_erp5_catalog_id only when we create new erp5_catalog

erp5_catalog: Use searchFolder as list method as we have catalog objects as content which are ERP5 object

erp5_catalog: Install erp5_catalog_transition bt before erp5_catalog_storage as we need Catalog portal type early on

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.