Fix v0.10.5 release blockers

[isc-dchui]

Fixes #999
Fixes #1000
Fixes #1007
Fixes #1015

[isc-kiyer]

@isc-dchui few minor comments. Looks good!

[isc-kiyer]

Can this not be called from the Invoke() in IPM.Installer above in the XData block instead? It should also probably query all namespaces on the instance to fix these mappings in namespaces that map IPM instead of installing it in there

[isc-dchui]

I tried that and it didn't work. For details, I set up the old mappings using

do ##class(%IPM.Utils.Module).AddGlobalMapping($namespace,"oddStudioDocument:(BEGIN):(""%ZP"")","IRISLIB")
do ##class(%IPM.Utils.Module).AddGlobalMapping($namespace,"oddStudioDocument:(""%ZP""):(""A"")","IRISSYS")
do ##class(%IPM.Utils.Module).AddGlobalMapping($namespace,"oddStudioDocument:(""Ens""):(""Ent"")","ENSLIB")

then called load /home/irisowner/zpm to install IPM again, which resulted in this error:

ERROR! User defined document 'ZPM.ZPM' not supported. No user defined document class in this namespace.
  > ERROR #6315: Errors reporting importing XML subelement in file '/home/irisowner/zpm/module.xml' at line '3' offset '28', skipping this item.

It seems the problem is that the mappings break IPM before any of the lifecycle stages can happen, which is when an <Invoke> would occur.

Good call on checking the other namespaces though, I've added that change.

[isc-kiyer]

@isc-dchui Hmm I think I was unclear. I meant the Invoke() in IPM.Installer as part of the installer manifest. Also, to test this, we should emulate how a customer would install IPM which loads IPM.Installer and runs the installer manifest from there instead of using load directly on IPM source files.