HstServices#getImplementationVersion() might not work in non-Tomcat or jar-non-exploded envs

HstServices#getImplementationVersion() manipulates a URL by using "../../../../" from HstServices package to retrieve MANIFEST.MF.
This might work if the jar URL is local file system based. e.g, jar:file:/opt/tomcat/webapps/site/WEB-INF/lib/hst-commons-x.x.x.jar!... in Tomcat.
However, this might not work depending if the container uses a different URL provider backend. e.g, WebLogic's classloader and its jar URL may differ and it's not guaranteed to work with "../../../../" in JAR / classpath URLs to read other resources.

Actually, there's a easier and safer way to read the "Implementation-Version" attribute from the MANIFEST.MF as long as it's inside a JAR with the MANIFEST.MF. For example,

System.out.println("Implementation-Version: " + HstServices.class.getPackage().getImplementationVersion());

A classloader implementation of a servlet container is supposed to provide Package#getImplementationVersion() properly, regardless of its own URL providers. [1]

I think we'd better change it to this simplest version. (The current implementation is error-pron and not safe in different containers such as WebLogic.)

[1] https://docs.oracle.com/javase/8/docs/api/java/lang/Package.html

Package objects contain version information about the implementation and specification of a Java package. This versioning information is retrieved and made available by the ClassLoader instance that loaded the class(es). Typically, it is stored in the manifest that is distributed with the classes.