Move out newClassLoadingContext out of the base API to a helper method.

Solving the following problems:
  * Doesn't need to be a base API, using only publicly available data
  * Wasn't really clear what we get depending on whether called from a CatalogItemDo, CatalogItemDtoAbstract, with null or non-null mgmt argument, due to the recursive nature of the creation.
  * We were getting loads of nested sequential loaders due to the recursive nature of building them.
  * Not possible to create a loader without access to an existing CatalogItem (which is the trigger cause for the changes, preparing the ground for the next commit)
Mark the wrapper app when instantiating from CAMP.
Promote catalog items to TEMPLATE if the root entity is an App.

Creates a spec for the item when adding to the catalog so the app check can be made, which means that addItem behaviour switches from lazy to eager instantiation (though the spec isn't kept long-term atm).
This closes #211