Support config "templating" based on HST root node

Currently, all HCM config and content is expected to contain full absolute paths for all JCR nodes being defined. This is problematic in the case of independent site development, since we want to reuse logical units of config and content (at the module level) for different site implementations defined with different HST root nodes. For example, some Essentials plugins provide config in the form of HCM modules added as dependencies to an implementation project when the plugin is installed.

The platform team's proposal is to introduce the concept of a "template" module, which uses the default "/hst:hst" root node in the YAML text, but which produces an actual effect parameterized based on the HST root node used in a specific HST site-war project.

We also propose that the initial implementation will be specific to this HST use case, rather than a general templating approach, to limit the potential complexity. The trigger for this dynamic replacement of JCR paths will be based on the context of where the HCM module is loaded and not based on any signal in the HCM module itself.

This approach will require treating (some) HCM modules as templates that can be instantiated with an HST root node parameter. This will affect at minimum ClasspathConfigurationModelReader, ConfigurationBaselineServiceImpl, ConfigurationServiceImpl, and ConfigurationModelImpl, which will need to be aware of the distinction between the template and instances, apply the correct HST root nodes, and compare digests correctly.