Internal Changes to the Catalog to reduce memory use and in some cases go faster

Remove "]" from the catalog text format ( I sh*t you not ).
Make the Java CatalogType more straightforward, using fewer collections.
Remove catalog classes in the EE that the EE doesn't use for memory reasons.
Other profiling-driving optimizations.

This may not be 100% ready to merge, and it may need some cleanup. Working on it.
This rewrite of the overrides for setBaseValues shines a light on how overly complex they are,
basically from setBaseValues wanting to be 2 simple but different things.

Thing1 is the method on CatalogType that sets the parentMap and type name of the object. This method (final even) could be called in exactly 2 places -- CatalogMap.add and CatalogType.deepCopy -- rather than from each generated class.

You might even want to TRUST this final method to do its job, and eliminate this bit of paranoid redundancy from CatalogMap.add :

            x.m_parentMap = this;

Thing2 is the generated custom method that allocates the child maps for each class. Assuming that it is called AFTER Thing1, since the generated classes never inherit (except from CatalogType) it needs no "super" call and no argument passing.

I suspect Thing1 would logically inherit the legacy name setBaseValues, but I'm not terribly fond of that name, so I don't much care.

In any case, you should drop the comment on setBaseValues or its successor that lies about it being called only by CatalogMap.add -- to say the least, that ignores CatalogType.deepCopy.

Maybe Thing2 could be called initFields analogous to copyFields.