Minor improvements for dynamic beans codebase

A number of small improvements and suggestions for the code under org.hippoecm.hst.content.beans.builder and org.hippoecm.hst.content.beans.dynamic

• Rename org.hippoecm.hst.content.beans.builder.HippoContentBean to DynamicContentBean, DynamicBeanDefinition, RuntimeBean or something similar. This can help distinguish this, substantially different, class from other similarly named, like org.hippoecm.hst.content.beans.standard.ContentBean, org.hippoecm.hst.content.beans.standard.HippoBean, org.hippoecm.hst.content.beans.standard.HippoDocumentBean

• Method public Class<? extends HippoBean> org.hippoecm.hst.content.beans.builder.HippoContentBean#getParentBean feels so close to public HippoBean org.hippoecm.hst.content.beans.standard.HippoItem#getParentBean, yet they have a vastly different usage. Consider renaming the first

• In general, using variable names like contentBean can be confusing, as traditionally this name is used for a pojo holding repository content, while here these are pojos that hold data used in generating runtime classes

• Add comments/javadoc to explain more that the code looks at jcr supertypes and recursively generates classes for parent doctype definitions. This isn't apparent, the only case where it is indirectly explained is in org.hippoecm.hst.content.beans.dynamic.DynamicBeanDefinitionService#createBeanDefinition, code:

  log.error("Document {} can't be generated because it doesn't have any relevant supertypes.", contentBean.getDocumentType());

• Rename method org.hippoecm.hst.content.beans.manager.DynamicObjectConverterImpl#shouldGenerateEnhancedBean as it does not check whether an enhanced bean should be generated, but rather whether it is allowed to be generated

• Rename variable parentRuntimeBeanContent to parentRuntimeContentBean in org.hippoecm.hst.content.beans.dynamic.DynamicBeanDefinitionService#setOrCreateParentBeanDefinition

• Rename method createBeanDefinition to something like createDynamicBeanClass, createRuntimeClass or similar, in org.hippoecm.hst.content.beans.dynamic.DynamicBeanDefinitionService

• In org.hippoecm.hst.content.beans.dynamic.DynamicBeanDefinitionService#assignGalleryTypes, the available gallery types are retrieved in a, imo, very fragile and dependent way:

  galleryTypes = gallery.getMultipleProperty(HIPPOSTD_GALLERYTYPE);

  Retrieving configuration from a content node does not sound a very good idea. Can't this information be retrieved by the contentTypeService?