Adjust Undertow's HttpInvoker service to use Host-based path registration

The Undertow HttpInvoker service allows an external client to interact with the server via Undertow and the wildfly-http-client library interfaces (EJB/HTTP, Transactions/HTTP and Naming/HTTP). Various services are involved to support this feature:

• RemoteHttpInvokerService (installed in Undertow subsystem)
• HttpInvokerHostService (installed in Undertow subsystem)
• EjbRemoteHTTPService (installed in ejb3 subsystem)
• TransactionRemoteHttpService (installed in transaction subsystem)
• HttpRemoteNamingService (installed in namin subsystem)

Undertow uses the RemoteHttpInvokerService to create a base PathHandler which is used to install the HTTP context paths and their corresponding handlers. The HttpInvokerHostService is a per-Host version of this idea same idea which depends on the RemoteHttpInvokerService and allows specifying the base context path under which the services are made available (e.g. /wildfly-services). Finally, the ejb3/transaction and naming subsystems install the respective services listed above to install paths and handlers for the EJB/HTTP, Transactions/HTTP and Naming/HTTP services, and these depend also on the HttpRemoteInvokerService.

 The problem with the current arrangement is that the RemoteHttpInvokerService and the three application level services are installed in such a way that they are outside the scope of any given Host defined within a server on the Undertow instance. This means that the handlers installed do not have access to Host-specific information, such as the domain name and port of the virtual hosts. This information is required to solve the issue WEJBHTTP-81.