Treating SparkUI as a handler of MasterUI

The main purpose for this is to avoid starting a new Jetty server for
each reconstructed SparkUI. This involves refactoring the existing way
of organizing handlers.

In particular, we currently use an immutable HandlerList to group all
handlers belonging to the same UI. However, this commit requires us to
attach handlers dynamically to a server after it has already started.
A further complication is that the simple HandlerCollection, which can
be mutable, does not perform longest prefix matching, such that a new
context can be engulfed by an existing one (which is extremely difficult
to debug, as the Jetty API is just absolutely superb).

With this commit, attached SparkUIs no longer need to start their own
servers, but simply reside under the /history prefix of the Master Web
UI.