(PUP-3755) Use catalog's environment when filtering it

When a catalog is produced, it is at one point filtered for
exported resources. The code path leading to this have lost the
knowledge of in which the environment the catalog was produced
and when it calls Catalog.filter, this takes place in the default
environment.

During the filtering, new resources are created. These resources do not
know why they are being created, if they will end up in a catalog or
not. Unless they are associated with a catalog, they have to lookup the
current_environment from the context.

Then, when a resource is being processed, it may need the Type, and if
so, and it is not already loaded a full import of the
current_environment will take place.

Since the call to filter the catalog took place from logic where the
environment is not know, the operatoin will fail if the default loaded
environment has errors. It may also produce the wrong result since it
may get information that is incompatible with the environment used to
compile the catalog.

The fix is to pick up the environment_instance set in the produced
catalog and to make the call to filter the catalog in a context where
this environment is set as the current_environment