Redesign how PageComposer loads ParametersInfo objects from site

This issue started out small but became a massive design discussion. HSTTWO-4422 tracks the original (small) issue, and HSTTWO-4377 continues the design discussion it grew to become. (I closed HSTTWO-4377 to mark that the commit linked to it is ready to ship. Unfortunately, all the interesting comments are still over there.)

== Old description below ==

The ContainerItemComponentServiceImpl in the page composer is used to 'know' which properties (parameter names and values) correspond to which type of fields. This is done as follows:

The ContainerItemComponentServiceImpl gets invoked from ContainerItemComponentResource which is a 'rest kind of' endpoint invoked over the platform webapp (/cms). In ContainerItemComponentServiceImpl, the backing jcr node of a container item is fetched, which typically has two multi-valued parameternames and parametervalues properties. How to display the names and values can only be known after
1) Fetching the backing hst component class
2) Inspecting whether the hst component class has a ParametersInfo annotation and if so, return a proxy of the ParametersInfo class.
3) After that, the class which is referenced by the ParametersInfo by type() is used to check for the existence of @Parameter annotations which tell how every name-value pair should be displayed (as in string, date, long, picker, etc)

The problem is currently only in (1) : The hst component class 'lives' in the hst site webapps, while the code above gets invoked from the hst page composer which only lives in the platform webapp. To be able to load the component class the website classloader is required. Since ParametersInfo and Parameter annotations are in shared lib, it is not needed for these.