(PUP-1699) Tie resource environment to catalog

Previously resources would end up "floating away" from the catalog that
contained them because they wouldn't use the catalog as their
source for an environment. This also extended to catalogs, which lost
track of their environment at times. So in order to have resources use
the environment of their catalog, the catalog needed to have a
guaranteed environment.

This adds an environment parameter to the catalog constructor and uses
it to drive the environment to use for everything in that catalog. The
resource now uses its catalog's environment, if it has a catalog, or it
uses the new NONE environment, if it does not have a catalog.

When catalogs are deserialized, they also need to have a reference to
*some* environment. However, since they only have a name of the
environment, there isn't any guarantee that an environment of that name
is available locally. To deal with this there is a new "remote"
environment constructor to be able to create references to the remote
environment of the catalog. This is used as the environment of a
deserialized catalog.

We (Joshua Partlow and Andrew Parker) tried to have the environment a
required parameter of catalog construction, but it appears that creating
catalogs is public API and so cannot be changed (we verified this by
checking stdlib tests).