As now, we expect our catalog object to be erp5 catalog and not indexable,
so its important to not reindex or unindex the old object.

Earlier, In ERP5Site, we use property 'isIndexable' to have control over indexing and unindexing.
This was usefull specially in case of bootstrap. To have this control, we had a function
`isIndexable` in SQLCatalog which we used to switch for enabling-disabling indexation. (769f9fb2)

Now, we do have ERP5 Catalog, which itself is an ERP5 Object, hence it has an accessor `isIndexable`
of itself which we plan to disable for now(as we don't want circular dependency while indexing
catalog in itself). But as we did have a function `isIndexable` in SQLCatalog which had control
over the indexing, we needed to rename this property for ERP5Site.

Hence, now we use property 'isIndexingRequired' for ERP5Site and use to have overall control
over indexing process.

Please note, we do not intend to change the same property name for any other object. Its just
for ERP5Site.

Required as most of the changes we have are in erp5_core and that's
why its important to install/update it before we install erp5_catalog_storage
bt5.

For compatibilty, we have added 2 extra functions, but in no way we need
to use this attribute as it doesn't give any meaning for ERP5CatalogTool
to have a default SQL Catalog.

This would increase compatibility between accessors in erp5_catalog and
remove the need of copy and patch. At the same time, it also helps in
increasing performance as using _getOb is always less costly than
getattr, as it reduces the need to look in acquisition.

After adding document component object, _p_oid was bing generated at the
last step of commit hook. This led to problem that _registry_dict for
dynamic_class 'erp5.component.document' wasn't getting updated with
the _p_oid of the component created. This led to failing of test because
to validate object with same reference, the checkConsistency function
checks in the _registry_dict for reference and _p_oid.

Explicilty calling commit here generates the oid before validation, hence
make it available for the registry_dict in time.

But, this clearly is a workaround which is clearly not solving the real
problem of why the _p_oid isn't being generated at the right step.

Also, me(Ayush), tried to recreate this error on a running instance, but
it worked fine there.

Earlier, class for any Catalog object used to be Products.ZSQLCatalog.SQLCatalog,
but now as we have shifted SQLCatalog to ERP5Catalog, the catalog objects have
lazy_class 'erp5.portal_type.Catalog' as their 1st class in mro. This class
don't have the required attributes.

The lazy_class is dynamic, so its not possible for them to save reserved IDs
as their attributes. So, we use the next class in mro, which would be
class 'Products.ERP5Catalog.ERP5Catalog' and save attributes in it.

Notice that this change of 'self.__klass__' is not required if
we are starting a lock with '_reserved_uid_lock' and then acquire-release it
consicutively in one go(transaction).

Create FilterDict and Filter class which would be used to imitate the behaviour
of filter_dict for Catalog.

And, Patch changeObjectClass extension to remove useless attributes

Copying __dict__ from one object to another brings us to situation where
we don have many objects which we don't need at all, for example, migrating
objects with subclasses who were initially OFS objects and later an ERP5
object can lead to adding subobjects as attributes of the new object, which
is completely undesirable. To handle this, it is important to delete the
sub-objects as the attributes for those migrated classes.

erp5_catalog: Refactor _bootstrap for Catalog Tool

Old Catalog Tool didn't have portal_type attribute, so while migrating
via synchronizeDynamicModule, after _bootstrap, we expect the tool to
have a portal_type to finalize migration.

This step is now being done only at the end of _bootstrap after we
change the classes for portal_catalog and its sub-objects.

And, changes to improve performance while dynamic migration.

XXX: Still at this point we are not doing the same thing with
sub-objects of catalog tool and wait till business template
installation.

erp5_catalog: Update attributes of the portal_catalog object after migration

One of the difference between SQL and ERP5 Catalog is how they
handle their properties. For ERP5Catalog, we use property_sheets
which generate setters and getters, for SQLCatalog, properties
just act as attributes(as one can expect from a property set
on a class).

This creates a difference on how we use them, especially for
list_type properties, which have accessors like get<PropertyName>List
to get the list of objects. For SQLCatalog, there is no such thing.
This creates problem whereever 'get<PropertyName>' or getProperty(<name>)
was being used to get multiple property types.

So, we changed this to rely on getattr for the Python Scripts in this
commit. Note that, getattr isn't good if we care about performance,
but given that its used only twice, this can be better than adding
extra function overhead.