Enable Hateoas in project with servicenames (Kubernetes, Consul, Eureka, ...)

Following up to #107
To be able to create links for a service based on it's servicename, which is used especially in Microservice environments that use consul, eureka or even kubernetes, you wouldn't want to create links pointing to the instance of the service, instead you need to create links pointing to the servicename, so any instance of the service can process further requests.

The current workaround is to create a filter that fakes X-Forwarding-host headers to trick another filter to create the right settings. This seems to be very hacky and hard to understand and maintain in the long run, as it's not very obvious.

It would be much better to have a dedicated setting that overrides the port/protocol and hostname. The most flexible solution would be a class that can be provided for that, but I'm not sure if that is overkill.

I'm also not completely sure if that mechanism shouldn't be in spring itself.

Review issue #107 and the current filter-based workaround involving X-Forwarded-Host headers. Determine where Spring HATEOAS builds service links and whether a configurable protocol, host, and port mechanism belongs in this project; done requires an agreed design and behavior for service-name-based links in microservice environments.