Support non file based config loading for hocon

[Katrix]

Using Configurate for a project outside the Sponge ecosystem, replacing it with the lower level typesafe config. However, I still want to use typesafe config's config loading (ConfigFactory.load and friends) which properly handle both application.conf and reference.conf files. At the moment I can't find any way to do so. Would be great if such an option was added.

[zml2008]

With the new direction I'm taking for loaders to allow replacing the underlying implementation, I won't be able to directly expose this in 4.x. It should be possible to implement the relationship between files in Configurate itself though, which would allow the same structure with any file format.

For reference from the HOCON spec:

By convention, JVM apps have two parts to their configuration:

the reference config is made up of all resources named reference.conf on the classpath, merged in the order they are returned by ClassLoader.getResources(); also, system property overrides are applied.
the application config can be loaded from anywhere an application likes, but by default if the application doesn't provide a config it would be loaded from files application.{conf,json,properties} on the classpath and then system property overrides are applied.
the reference config may be different for different class loaders, since each jar may provide a reference.conf to go with the code in that jar.
a single JVM may have multiple application configs if it has multiple modules or contexts of some kind.

The reference config for a given class loader should be merged and resolved first, and may be shared among all application configs in that class loader. Substitutions in the reference config are not affected by any application configs, because the reference config should be resolved by itself.

The application config should then be loaded, have the reference config added as a fallback, and have substitutions resolved. This means the application config can refer to the reference config in its substitutions.

This behaviour is further described in the HOCON README