Allow registering a custom HTTP handler for management interface

With WFCORE-1742, it is possible to add "resources" to the HTTP management interface through the ExtensibleHttpManagement interface.

However this requires to provide a io.undertow.server.handlers.resource.ResourceManager object that represents the resource. This interface is meant to represent static resources (such as file) and does not map well to exposing a "REST" kind of API.

It requires to provide cache metadata (etag, cache) that may not be relevant for a HTTP API.
It also automatically enables redirection (e.g. / to /index.html) without possibility to disable it.

For some HTTP API such as the one required by MicroProfile Health Check (a GET on /management/health), it would be better to be able to pass a io.undertow.server.HttpHandler instead of a io.undertow.server.handlers.resource.ResourceManager to have more flexibility/simplicity to provide management HTTP API.

One of the concern when WFCORE-1742 was created was that this API exposes Undertow API. This is already the case with ResourceManager and this RFE would only add exposition to the io.undertow.server.HttpHandler interface (in particular, the HttpServerExchange API is already exposed by the ResourceManager).
Proposed API:

in org.jboss.as.server.mgmt.domain.ExtensibleHttpManagement

    /**
     * Add a context for a HTTP management handler.
     * @param contextName the name of the context. Cannot be {@code null} or empty
     * @param managementHandler HTTP management handler. Cannot be {@code null}
     *
     * @throws IllegalArgumentException if either parameter is invalid
     * @throws IllegalStateException if there is already a context present named the same as {@code contextName}, either
     *                               added via this interface or otherwise
     */
    void addManagementHandler(String contextName, HttpHandler managementHandler);

(this is in addition to the existing addStaticContext(String contextName, ResourceManager resourceManager)).

There is no need to add a corresponding remove method as the existing one removeContext(String contextName) can be used.