In order to avoid the base encode/decode methods from being used (and
failing a static assertion), we must be sure to declare/define the
custom type implementations as template specializations.
After this, LibIPC is no longer sensitive to include order.
Success responses are meant to be wrapped in a JSON object with a single
"value" key. Instead of doing this in both WebContent and WebDriver, do
it once in LibWeb.
This moves communication and route matching for WebDriver endpoints into
LibWeb. This is to reduce the amount of duplication required to create a
WebDriver implementation for Ladybird.
In doing so, this introduces some cleanup of WebDriver handling. Routes
are now a compile-time array, and matching a route is nearly free of
allocations (we still allocate a Vector for parsed parameters). This
implementation also makes heavier use of TRY semantics to propagate
errors into one handler.
This will allow for implementing the screenshot action closer to the
spec, as we can now use HTMLCanvasElement to encode the bitmap, and
capture the screenshot on the animation frame loop.
This is essentially an ErrorOr<JsonValue, Web::WebDriver::Error> class.
Unfortunately, that ErrorOr would not be default-constructible, which is
required for the generated IPC classes. So this is a thin wrapper around
a Variant<JsonValue, Web::WebDriver::Error> to emulate ErrorOr.
This cannot be done on the Browser or WebDriver ends, or via the
existing run_javascript() IPC endpoint, as we cannot transfer JS objects
through the IPC boundary (yet), only serialized JSON, so the individual
WebDriver steps around script execution need to run in the WebContent
process.
