Add a servlet filter that does the reverse proxy work in translating html and javascript urls to the proxy based ones

Up until fixing GEOS-1655, all the ui code where replacing the request URIs by the proxyfied version for html links and javascript/css code.

Problem was it didn't work for proxy url's that replace the /geoserver context. That is, only the protocol, server and port were respected, among being the wrong way to handle URL translation, as it could be done by an external reverse proxy (as apache's mod_html).

Yet, fixing GEOS-1655 meant a regression. For the most simple case, as stated above, the replacement of protocol://host:port just worked, as long as /geoserver were the context path both at the servlet container and the proxy.

This task aims at fixing that regression as well as to provide a clean, single entry point, for a reverse proxy like content replacement that:

• is implemented as a servlet filter, translating the URLs in the output content, replacing them by the proxified version
• is configurable providing an all or nothing solution. It can either be enabled and thus all html, javascript and css urls will be proxified, or it could be disabled and thus no translation is made, implying the UI can only be accessed through the "intranet"
• the mime types for the proxified contents are configurable as a filter init parameter, using regular expressions
• not only protocol://host:port can be translated, but also an arbitrary context path, like using /geoserver/tools as the proxy entry point instead of the /geoserver servlet context

This way, the clear separation of concerns between UI code and reverse proxy remains and it could be reused out of the box no matter what UI technology is used in the future.
For the people not able to configure the proxy externally (like the ones using apache 1 instead of apache 2, for which mod_html is not available), there's an easy option to still be able of publishing the geoserver configuration ui through the proxy server.